Joint state estimation prediction that evaluates differences in predicted vs. corresponding received data

ABSTRACT

Systems and methods are provided for reconciling untrusted data of a subject using trusted data pertaining to the subject. Systems and methods are directed to evaluating differences in predicted data with respect to corresponding received data. Systems and methods estimate metabolic states from a combination of trusted and untrusted metabolic inputs, along with optionally using a personalized mathematical model with parameter optimization. Systems and methods provide for reconciled untrusted inputs with their measured impact of the glycemic signals that is consistent with a metabolic model. Estimation of future metabolic states for decision support and automated insulin dosing is enabled. Replay of scenarios with estimated or reconciled data is also provided.

INCORPORATION BY REFERENCE TO RELATED APPLICATIONS

Any and all priority claims identified in the Application Data Sheet, orany correction thereto, are hereby incorporated by reference under 37CFR 1.57. This application claims priority to U.S. Provisional PatentApplication No. 62/935,920, filed on Nov. 15, 2019, entitled “JOINTSTATE ESTIMATION PREDICTION THAT EVALUATES DIFFERENCES IN PREDICTED VS.CORRESPONDING RECEIVED DATA”. The aforementioned application isincorporated by reference herein in its entirety, and is herebyexpressly made a part of this specification.

BACKGROUND

With the growing adoption of CGM (continuous glucose monitoring) andconnected devices, the availability and reliability of glucosetime-series data has increased in recent years. However, despite theavailability of reliable glucose data, accurate tracking of insulin andmeal data and optimized and effective timing of meal time insulinbolusing continues to be problematic for many people with diabetesresulting in poor glucose control.

Nondiabetics have tightly controlled blood glucose (BG) values even withglucose input ranging from fasting to high carbohydrate (carb) meals andmetabolic demands ranging from sleeping to intense exercise. Forexample, CGM data in adults without diabetes has an average glucose of99 mg/dL and 97% time within the glycemic range of 70-140 mg/dl. Thistight control results from the combined actions of glucoregulatoryhormones, such as insulin, glucagon, amylin, and GLP-1 and theassociated messaging between organs like the pancreas, intestine, andliver.

In contrast, blood glucose control for type 1 diabetes has historicallyrelied on a simpler strategy of dosing insulin to cover meals and thebody's baseline requirements. An example routine would have a daily doseof long-acting insulin combined with pre-meal doses of fast-actinginsulin based on carb counting and self-monitored blood glucosemeasurements. The success of this approach relies on diligent attentionand assuming the body always responds the same way to food and insulindespite all the variability of meal choice, stress, exercise and thelike. As a result, most people are forced to strike a balance betweenavoiding the health risks of chronic high glucose and dangerous lowglucose episodes.

Improved glucose control for insulin-dependent diabetes depends, inpart, on a strategy that more closely mimics the way the pancreas adaptsto changing metabolic conditions. One example is the artificial pancreas(AP) system.

However, patient alerts and/or alarms and pharmaceutical dosingalgorithms often rely on the ability to either prospectively predictfuture metabolic states in real time or retrospectively simulating thephysiological circumstances of life with chronic illness. In turn,predicting the future depends on the ability to estimate the currentmetabolic state of the patient with all available data, including datareceived directly from the patient (e.g., voluntary acknowledgments ofmeal carbohydrates) that is prone to having errors (e.g., late orcompletely missing meal acknowledgements with substantiallyunderestimated carbohydrate counts). Even if algorithms predict datathat is currently unavailable, if/when that predicted data is received(e.g., later from a user), there are typically differences (i.e.,discrepancies). These discrepancies are currently unused, but ifevaluated, can provide valuable information about the data for futureuse. The systems and methods described herein use and reconcile theirdifferences.

There is a dilemma in combining human and machine inputs into ametabolic model. The most reliable inputs are machine recorded, such asthose from an insulin pump or a continuous glucose monitor so it istempting to ignore or avoid human inputs. The problem is that theglucose appearance in blood and CGM signal is delayed, even for fastacting carbohydrates. Thus, even an imperfectly announced or describedmeal will initially predict future glucose values better than a pre-mealCGM trace. Once the blood sugar has responded to the meal, the metabolicmodel can better describe the observed response. The systems and methodsdescribed herein seamlessly combine these two perspectives and reconciletheir differences.

SUMMARY

According to some aspects, systems and methods are provided forreconciling untrusted data of a subject using trusted data pertaining tothe subject. According to some aspects, systems and methods are directedto evaluating differences in predicted data with respect tocorresponding received data.

In an implementation, a method comprises receiving, at an inputestimator, untrusted data pertaining to a subject; receiving, at theinput estimator, trusted data pertaining to the subject; reconciling,using an input reconciler, the untrusted data using the trusted data;and outputting the reconciled untrusted data.

Implementations may include some or all of the following features. Theuntrusted data comprises at least one of timing of insulin, amount ofinsulin, meal data, or activity data. The untrusted data is untrustedbecause of behavioral anomalies or human error in at least one oftiming, amount, estimation, or entry. The trusted data comprises atleast one of CGM data, insulin pump data, computer generated data,computer generated models, or an individualized model that describes theglucose and insulin dynamics of the subject. The method furthercomprises predicting a future glucose state of the subject based on thereconciled untrusted data. The untrusted data comprises reported carbs,wherein the reported carbs are unreliable or unavailable. The untrusteddata comprises a stream of data inputs. The method further comprisesreceiving additional untrusted data and reconciling the additionaluntrusted data using the trusted data. The method further comprisesreceiving additional trusted data and reconciling the untrusted datausing the additional trusted data. The method further comprises tuningan AP using the reconciled untrusted data. The method further comprisesupdating a behavior model of the subject using the reconciled untrusteddata. The method further comprises determining that the untrusted datais unreliable or unknown. Determining that the untrusted data isunreliable or unknown comprises computing, using modeling, localvariance of the untrusted data and comparing the local variance to theoverall variance using the untrusted data to determine a comparisonamount, wherein when the comparison amount is above a threshold, theuntrusted data is determined to be unreliable or unknown. Determiningthat the untrusted data is unreliable or unknown comprises determiningdifferences between the untrusted data and a model of trusted data.

Implementations may also include some or all of the following features.The method further comprises determining a credibility score for theuntrusted data relative to trusted data. The method further comprisesgenerating alerts pertaining to the subject based on the reconcileduntrusted data. The method further comprises determining behaviorpatterns of the subject using the reconciled untrusted data. The methodfurther comprises generating smart alerts pertaining to the subjectbased on the behavior patterns. The untrusted data comprises diabetesmanagement data. The diabetes management data is estimated diabetesmanagement data. The trusted data comprises diabetes management datacorresponding to the estimated diabetes management data, wherein thediabetes management data is received from a connected device or userentry. The method further comprises comparing the untrusted data to thetrusted data to identify a behavioral root cause of glycemicdysfunction.

Implementations may also include some or all of the following features.The method further comprises identifying a behavioral root cause ofglycemic dysfunction using the reconciled untrusted data. Thereconciling comprises: receiving the untrusted data at the inputreconciler, wherein the untrusted data comprises untrusted metabolicinputs; receiving the trusted data at the input reconciler, wherein thetrusted data comprises estimated untrusted metabolic inputs; andcombining the untrusted data and the trusted data using a weightingfunction to generate reconciled untrusted metabolic inputs. Theuntrusted data and the trusted data received at the input reconciler arein the form of vectors, and the reconciled untrusted metabolic inputsare in the form of vectors. The weighting function is based ontime-relevance. The weighting function is based on relative confidenceof the untrusted data and the trusted data. The untrusted data comprisesreported untrusted metabolic inputs, and the combining comprisesreconciling differences between the reported untrusted metabolic inputsand the estimated untrusted metabolic inputs. The reconciling comprisesmaking the reported untrusted metabolic inputs and the estimateduntrusted metabolic inputs consistent with a behavior model. Thereconciling comprises reconciling differences between the amount andtiming of the untrusted metabolic inputs and the estimated untrustedmetabolic inputs with measured data.

In an implementation, a method comprises receiving, at an inputestimator, untrusted data pertaining to a subject, wherein the untrusteddata comprises user entered data comprising at least one of insulindata, meal data, or activity data; and reconciling, using an inputreconciler, the untrusted data using trusted data pertaining to thesubject, wherein the trusted data comprises computer generated data.

Implementations may include some or all of the following features. Theuntrusted data comprises at least one of timing of insulin, amount ofinsulin, meal data, or activity data. The untrusted data is untrustedbecause of behavioral anomalies or human error in at least one oftiming, amount, estimation, or entry. The trusted data comprises atleast one of CGM data, insulin pump data, computer generated models, oran individualized model that describes the glucose and insulin dynamicsof the subject. The method further comprises predicting a future glucosestate of the subject based on the reconciled untrusted data. Theuntrusted data comprises reported carbs, wherein the reported carbs areunreliable or unavailable. The untrusted data comprises a stream of datainputs. The method further comprises receiving additional untrusted dataand reconciling the additional untrusted data using the trusted data.The method further comprises receiving additional trusted data andreconciling the untrusted data using the additional trusted data. Themethod further comprises tuning an AP using the reconciled untrusteddata. The method further comprises updating a behavior model of thesubject using the reconciled untrusted data. The method furthercomprises determining that the untrusted data is unreliable or unknown.Determining that the untrusted data is unreliable or unknown comprisescomputing, using modeling, local variance of the untrusted data andcomparing the local variance to the overall variance using the untrusteddata to determine a comparison amount, wherein when the comparisonamount is above a threshold, the untrusted data is determined to beunreliable or unknown. Determining that the untrusted data is unreliableor unknown comprises determining differences between the untrusted dataand a model of trusted data. The method further comprises determining acredibility score for the untrusted data relative to trusted data. Themethod further comprises generating alerts pertaining to the subjectbased on the reconciled untrusted data. The method further comprisesdetermining behavior patterns of the subject using the reconcileduntrusted data. The method further comprises generating smart alertspertaining to the subject based on the behavior patterns.

Implementations may also include some or all of the following features.The untrusted data comprises diabetes management data. The diabetesmanagement data is estimated diabetes management data. The trusted datacomprises diabetes management data corresponding to the estimateddiabetes management data, wherein the diabetes management data isreceived from a connected device or user entry. The method furthercomprises comparing the untrusted data to the trusted data to identify abehavioral root cause of glycemic dysfunction. The method furthercomprises identifying a behavioral root cause of glycemic dysfunctionusing the reconciled untrusted data. The reconciling comprises:receiving the untrusted data at the input reconciler, wherein theuntrusted data comprises untrusted metabolic inputs; receiving thetrusted data at the input reconciler, wherein the trusted data comprisesestimated untrusted metabolic inputs; and combining the untrusted dataand the trusted data using a weighting function to generate reconcileduntrusted metabolic inputs. The untrusted data and the trusted datareceived at the input reconciler are in the form of vectors, and thereconciled untrusted metabolic inputs are in the form of vectors. Theweighting function is based on time-relevance. The weighting function isbased on relative confidence of the untrusted data and the trusted data.The untrusted data comprises reported untrusted metabolic inputs, andthe combining comprises reconciling differences between the reporteduntrusted metabolic inputs and the estimated untrusted metabolic inputs.The reconciling comprises making the reported untrusted metabolic inputsand the estimated untrusted metabolic inputs consistent with a behaviormodel. The reconciling comprises reconciling differences between theamount and timing of the untrusted metabolic inputs and the estimateduntrusted metabolic inputs with measured data. The method furthercomprises performing replay prediction using the reconciled untrusteddata and the trusted data. The method further comprises outputtingsimulated metabolic states based on the replay prediction. The methodfurther comprises performing real time prediction using the reconcileduntrusted data and the trusted data. The method further comprisesoutputting simulated metabolic states based on the real time prediction.

In an implementation, a method comprises predicting data over a timeperiod for a subject; receiving untrusted data directed to management ofdiabetes; simulating a plurality of predictive data traces over the timeperiod using a spectrum of possible variances of the untrusted data;comparing the simulated predictive data traces to the predicted data toidentify glycemic effects; and outputting a visualization or arecommendation based on the glycemic effects.

Implementations may include some or all of the following features. Theuntrusted data comprises glucose data, and the predictive data tracescomprise predictive glucose traces. Predicting the glucose data is basedon trusted CGM data and an individualized model of the glucose-insulinkinetics of the subject. Predicting the glucose data comprises providinga best estimate glucose trace representing glucose state over time. Theuntrusted data directed to management of diabetes comprises at least oneof a timing of insulin, an amount of insulin, meal data, or activitydata. The glycemic effects are associated with differences in at leastone of an amount of diabetes management data or a timing of diabetesmanagement data.

In an implementation, a system comprises a processor and a metabolicmodel, wherein the processor is configured to receive untrusted userinputs and reconcile the untrusted user inputs with trusted inputs usingthe metabolic model.

Implementations may include some or all of the following features. Theprocessor is further configured to optimize the predictive ability ofthe metabolic model to predict future glucose levels. The processor isfurther configured to allow a replay of events and outcomes withalternate treatment procedures. The processor is further configured toprovide real time prediction of future metabolic states. The processoris further configured to determine the credibility of the untrusted userinputs. The processor is further configured to provide a scorecorresponding the credibility. The processor is further configured toperform a replay analysis directed to at least one replay application.The at least one replay application comprises assessment of bloodglucose (BG) outcome metrics in the analysis, identification of credibleinstances of scenarios in the replay analysis, evaluation of dataquality, credibility profiles, and data credibility as a function oftime of day. The processor is further configured to perform a reconciledprojection directed to at least one real time application. The at leastone real time application comprises confidence of medical actions anddetermination of need to wait before providing advice.

Implementations may also include some or all of the following features.The untrusted user inputs comprise estimated carbs. The untrusted userinputs comprise a time series of uncertain metabolic inputs. The trustedinputs comprise CGM and insulin pump readings. The trusted inputscomprise a time series of trusted metabolic inputs. The processor isfurther configured to output estimated metabolic states in time seriesform, final reconciled estimated metabolic states in time series form,and credibility of final estimated metabolic states and reconciledestimated inputs in time series form. The processor is comprised withina joint state/input estimator, and the metabolic model is a plugin.

In an implementation, a method comprises receiving, at an inputestimator, untrusted data pertaining to a subject, wherein the untrusteddata comprises user entered data comprising at least one of insulindata, meal data, or activity data; determining, at a credibilityassessor, a credibility of the untrusted data; receiving trusted data atthe credibility assessor; and updating, at the credibility assessor, thecredibility of the untrusted data using the trusted data.

Implementations may include some or all of the following features.Determining the credibility of the untrusted data comprises: determininga first credibility based on at least one of a lack of completeness ofthe untrusted data or a lack of continuity of the untrusted data;determining a second credibility based on expected behaviors indicativeof at least one of the lack of completeness of the untrusted data or thelack of continuity of the untrusted data; determining a thirdcredibility based on artifacts in estimated inputs indicative ofsystemic unknown factors; and aggregating the first credibility, thesecond credibility, and the third credibility. Determining the firstcredibility comprises using measured signals as an input, determiningthe second credibility comprises using the untrusted data and trusteddata as inputs, and determining the third credibility comprises usingthe untrusted data, estimated untrusted data, and reconciled data asinputs.

In an implementation, a method comprises receiving, at an inputestimator, first untrusted data pertaining to a subject, wherein thefirst untrusted data comprises user entered data comprising at least oneof insulin data, meal data, or activity data; determining, at acredibility assessor, a credibility of the first untrusted data;receiving, at the input estimator, second untrusted data pertaining tothe subject; determining, at a credibility assessor, a credibility ofthe second untrusted data; updating, at the credibility assessor, thecredibility of the first untrusted data using the second untrusted dataor the credibility of the second untrusted data; receiving trusted dataat the credibility assessor; and updating, at the credibility assessor,the credibility of the first untrusted data and the second untrusteddata using the trusted data.

Implementations may include some or all of the following features.Determining the first credibility of the untrusted data comprises:determining a first credibility based on at least one of a lack ofcompleteness of the untrusted data or a lack of continuity of theuntrusted data; determining a second credibility based on expectedbehaviors indicative of at least one of the lack of completeness of theuntrusted data or the lack of continuity of the untrusted data;determining a third credibility based on artifacts in estimated inputsindicative of systemic unknown factors; and aggregating the firstcredibility, the second credibility, and the third credibility.Determining the first credibility comprises using measured signals as aninput, determining the second credibility comprises using the untrusteddata and trusted data as inputs, and determining the third credibilitycomprises using the untrusted data, estimated untrusted data, andreconciled data as inputs.

In an implementation, a method comprises receiving estimated metabolicstates, reconciled estimated untrusted metabolic inputs, trustedmetabolic inputs, and alternative metabolic inputs; performing replayprediction using the estimated metabolic states, the reconciledestimated untrusted metabolic inputs, the trusted metabolic inputs, andthe alternative metabolic inputs; and outputting replay simulatedmetabolic states based on the replay prediction.

Implementations may include some or all of the following features. Theestimated metabolic states, the reconciled estimated untrusted metabolicinputs, and the trusted metabolic inputs each comprise a time series.Performing the replay prediction comprises estimating metabolic statesfor a duration of the time series for the estimated metabolic states,the reconciled estimated untrusted metabolic inputs, and the trustedmetabolic inputs to generate the replay simulated metabolic states.

In an implementation, a method comprises receiving alternative metabolicinputs, reconciled estimated untrusted metabolic inputs, trustedmetabolic inputs, and final estimated metabolic inputs; performing realtime prediction using the alternative metabolic inputs, the reconciledestimated untrusted metabolic inputs, the trusted metabolic inputs, andthe final estimated metabolic inputs; and outputting predicted metabolicstates based on the real time prediction.

Implementations may include some or all of the following features.Performing the real time prediction comprises: extrapolating time seriesfor the reconciled estimated untrusted metabolic inputs and the trustedmetabolic inputs; and estimating metabolic states into the future usingthe extrapolated time series, the alternative metabolic inputs, and thefinal estimated metabolic states. The method further comprises filteringthe extrapolated time series to prevent jitter in the predictedmetabolic states. The estimated metabolic states are in time seriesform. The method further comprises filtering the estimated metabolicstates to generate the predicted metabolic states. The estimating themetabolic states uses a behavior model of a subject. Extrapolating thetime series uses weighting of historical data based on at least one of atime of day, features of a current estimated state, or a database ofpast metabolic inputs.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofillustrative embodiments, is better understood when read in conjunctionwith the appended drawings. For the purpose of illustrating theembodiments, there is shown in the drawings example constructions of theembodiments; however, the embodiments are not limited to the specificmethods and instrumentalities disclosed. In the drawings:

FIG. 1 is an illustration of an exemplary environment for evaluating andvisualizing differences in data;

FIG. 2 is a block diagram of an implementation of a diabetes managementprocessing platform;

FIG. 3 is a block diagram of an implementation of a retrospective inputcompiler;

FIG. 4 is a block diagram an implementation of a live input compiler;

FIG. 5 is a block diagram an implementation of a replay compiler;

FIG. 6 is a block diagram of an implementation of a prediction engine;

FIG. 7 is a block diagram of an implementation of a parameter estimator;

FIG. 8 is an operational flow of an implementation of a method forreconciling data;

FIG. 9 is an operational flow of another implementation of a method forreconciling data;

FIG. 10 is an operational flow of an implementation of a method fordetermining the credibility of data;

FIG. 11 is an operational flow of another implementation of a method fordetermining the credibility of data;

FIG. 12 is an operational flow of an implementation of a method forusing untrusted data to provide output based on glycemic effects;

FIG. 13 is an operational flow of an implementation of a method forusing replay prediction;

FIG. 14 is an operational flow of an implementation of a method forusing real time prediction; and

FIG. 15 shows an exemplary computing environment in which exampleembodiments and aspects may be implemented.

DETAILED DESCRIPTION

The claimed subject matter is described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the claimed subject matter. It may be evident, however,that the claimed subject matter may be practiced without these specificdetails. In other instances, structures and devices are shown in blockdiagram form in order to facilitate describing the claimed subjectmatter.

The description is not to be taken in a limiting sense, but is mademerely for the purpose of illustrating the general principles of theinvention, since the scope of the invention is best defined by theappended claims.

Various inventive features are described herein that can each be usedindependently of one another or in combination with other features.

Unmeasured human behaviors and untrustworthy reporting of relevantmetabolic events (e.g., meals and boluses) are much more impactful thanthe effects of sensor error on inferences from signal processing ofglucose time series data. Consequently, untrusted data can be reconciledwith trusted data, providing reconciled untrusted and trusted data asestimated metabolic data useful for prediction or replay of glucose timeseries data.

In some aspects, systems and methods are provided for reconcilinguntrusted data of a subject using trusted data pertaining to thesubject. In some aspects, systems and methods are directed to evaluatingdifferences in predicted data with respect to corresponding receiveddata.

As described further herein, a retrospective prediction functionevaluates if other insulin dosing strategies for the same meal wouldhave better outcomes (e.g., lower glycemic risk). The retrospectiveprediction function takes the initial (e.g., premeal) state of thepatient, one or more meal events, and an insulin dosing strategy asinputs and then maps it to the resulting glucose excursions for thatmeal/day. In some implementations, the retrospective predictionfunction: (1) maps the original data (e.g., meal and insulin) to theobservations (e.g., CGM) with a sufficient (e.g., predetermined) degreeof accuracy, (2) maps alternate dosing strategies to the resultingglucose excursions in manner that models the patient's (the patient isalso referred to herein as “the subject”) physiology (e.g., insulinactivity and carbohydrate sensitivity), and (3) provides reliable andinterpretable solutions to the problem such as an estimate of insulin onboard that is a stable and smooth function. Joint state estimator andmeal estimation systems and methods herein combine known inputs anduser-announced meals to solve for this function. The output of is afunction that can replay alternate insulin strategies with the sameinputs' states (or the results of the alternate insulin strategiesthemselves).

In an implementation, the replay function may be constructed from thesame data set using other approaches known to one skilled in the art ofmetabolic models. One example approach would be to fit the parameters ofa known metabolic model to the patient's data or a clinical study.Another possible approach would be to train a neural network withsimilar data to predict the glucose excursions.

FIG. 1 is an illustration of an exemplary environment 100 for evaluatingand visualizing differences in data. The environment comprises aninsulin device 110, a glucose monitor 120, a processor 130, a subject140, an activity monitor 150, and a smartphone 160.

One or more of the insulin device 110, the glucose monitor 120, theprocessor 130, the activity monitor 150, and the smartphone 160 may bein communication through a network. The network may be a variety ofnetwork types including the public switched telephone network (PSTN), acellular telephone network, and a packet switched network (e.g., theInternet). Although only insulin device 110, one glucose monitor 120,one processor 130, one subject 140, one activity monitor 150, and onesmartphone 160 are shown in FIG. 1, there is no limit to the number ofinsulin devices 110, glucose monitors 120, processors 130, subjects 140,activity monitors 150, and smartphones 160 that may be supported.

The insulin device 110 may be any device that dispenses insulin, such assyringes, pumps (e.g., external, mechanical, patch, or implanted), andinhalers, for example. The insulin device 110 may also include devicesthat dispense other drugs that help control glucose levels like glucagon(dual-hormone artificial pancreas), GLP-1, etc.

The glucose monitor 120 may be any type of CGM or SMBG (self-monitoringof blood glucose) device, depending on the implementation. The glucosemonitor 120 may be a connected device that provides glucose readingscontinuously or provides a set of glucose readings when the device isscanned or downloaded. In addition to glucose readings, the glucosemonitor 120 may record user interactions such as when and how a user(e.g., a subject, a patient, a caregiver, a medical professional, etc.)views their glucose traces and how they respond to alerts and alarms.The user interaction can provide insights into the timing and motivationof treatment decisions including why and when they are considering theeffects of eating or dosing insulin.

The processor 130 collects data from the insulin device 110 and theglucose monitor 120 and the subject 140 and runs methods describedherein. To have a robust system, these calculations may be dynamic anddistributed depending on which devices and processors are connected. Forexample, cloud computing may be used when there is connectivity, asmartphone processor may be used when there is no connectivity and thena transmitter or a smartwatch may be used when the smartphone is notconnected. Complex calculations, like model optimization, may only runwhen more powerful processors are available. When powerful processorsare not available, algorithms may use the most recent parameters orsimpler approximations.

The processor 130 (as well as the insulin device 110, the glucosemonitor 120, the activity monitor 150, and/or the smartphone 160) may beimplemented using a variety of computing devices such as smartphones,desktop computers, laptop computers, and tablets, for example. Othertypes of computing devices may be supported. A suitable computing deviceis illustrated in FIG. 15 as the computing device 1500.

The subject 140 can provide inputs to the system including informationabout meals, activity, and diabetes treatments using e.g., any computingdevice that is in communication with the system, such as the smartphone160 or other computing device of the subject 140. These inputs can beuser-initiated or prompted by the system. These inputs can describecurrent, previous, and/or upcoming events.

The activity monitor 150 may be any device that monitors the user'sphysiologic and mental state. One example is a fitness tracker thatmonitors activity, exercise, and sleep with accelerometers, gyroscopes,heart rate, and oxygen sensors. This can also include smartphones asthey can detect location and user activity/interactions, or a smart homedevice (e.g., Amazon Alexa). In some implementations, the activitymonitor 150 includes devices that detect meals.

The smartphone 160 can be used as an activity and context monitor, dataentry device, data collection (talking to devices with Bluetooth, NFC,Wi-Fi, etc.) and run applications (e.g., apps) that estimate nutritionalinformation through manual entry or automated entry (e.g., photos).

The systems and methods described herein estimate metabolic states froma combination of trusted and untrusted metabolic inputs, along withoptionally using a personalized mathematical model with parameteroptimization. Systems and methods provide for reconciled untrustedinputs with their measured impact of the glycemic signals (using CGM)that is consistent with the metabolic model (optional). Estimation offuture metabolic states for decision support and automated insulindosing is enabled with the systems and methods described herein.Credibility of the data, for example, rather than declaring whole daysas being valid or invalid, and providing a time series of credibilitydata alongside the metabolic state estimates avoids problems to modelinga continuous process such as overnight predictions. Replay of scenarioswith estimated or reconciled data is also provided. All data, includingmetabolic states (trusted and untrusted reconciled), along withcorresponding credibility, prediction and replay are provided in atime-domain perspective. Retrospective predictions, also referred to asreplay compiling, and prospective prediction, also referred to real timeprediction compiling, are made more reliable and accurate by thereconciliation process(es) of implementations described herein.

FIG. 2 is a block diagram of an implementation of a diabetes managementprocessing platform 200. The platform 200 uses reconciliation, replayanalysis, prediction and/or credibility determination together with anoptional optimization of parameters to predict future analyte values orunobserved states, inform bolus decisions, assess carbs on board, assessinsulin on board, enable smart alert functionality, deliverretrospective therapy optimization, and to provide feedback toestimation, for example. The diabetes management platform 200 includesinputs, outputs, and interrelationships of the modules, are describedfurther herein.

The platform 200 comprises an input compiler 220, a replay compiler 230,a prediction engine 250, and a parameter estimator 270. The inputcompiler 220 comprises a retrospective input compiler 220R and a liveinput compiler 220L. The platform 200 may comprise more or fewer modulesdepending on the implementation. In some implementations, for example,the parameter estimator 270 is optional.

Data is provided to the input compiler 220 and may include measuredsignals, indirectly observed metabolic inputs that are trustworthy(i.e., trusted metabolic inputs), indirectly observed metabolic inputsthat are not trustworthy (i.e., untrusted metabolic inputs), along withan estimated initial state that describes the condition of the patientat the time of the first data point. Examples of measured signalsinclude blood glucose data from a blood glucose monitor (BGM) or acontinuous glucose monitor or insulin delivery data from a connectedinsulin pen or an insulin pump. Examples of trusted metabolic inputsinclude reports of meal activity or physical activity from professionalcaregivers in a clinical setting with assurances of accuracy in terms oftiming, degree, and content. Examples of untrusted metabolic inputsinclude reports of meal activity or physical activity in the field usingpencil/paper (e.g., handwritten) diaries or logging functions of medicaldevices that have no means of enforcing accuracy.

The input compiler 220 processes retrospective data 210 using theretrospective input compiler 220R and processes live data 212 using thelive input compiler 220L. Retrospective data 210 is provided to theretrospective input compiler 220R and the parameter estimator 270 and isfurther described with respect to FIG. 3 and FIG. 9 for example. Livedata 212 is provided to the live input compiler 220L. Live data 212 isreal time or within a particular time window or during a processingcycle or the like, depending on the implementation. Live data 212 isfurther described with respect to FIG. 6 and FIG. 9 for example.

In an implementation, the input compiler 220 comprises a state estimator(e.g., the state estimator 340 shown in FIGS. 3 and 6), which may use anindividualized physiological model to produce outputs such as reconciledestimated metabolic inputs, estimated metabolic states of the patientfor the duration of the input data, a numerical assessment of thecredibility of the estimated states and, and a numerical assessment ofthe credibility of the reconciled estimated metabolic inputs. Thereconciled estimated metabolic inputs are used along with their linkageto the assessment of the credibility of the estimated metabolic statesand the credibility of the reconciled estimated metabolic inputs. Inaddition to their use within the interrelated modules of the system, thereconciled data, such as reconciled meal and insulin histories can bereported back out to the patient or other user.

The replay compiler 230 uses the output 225R of the input compiler 220operating on retrospective data 210 (i.e., the output 225R of theretrospective input compiler 220R), along with a state estimator usingestimated model parameters 275, which may be an individualizedphysiological model, and replay user requirements and component models235, to produce output such as replay predictive function 240 and/orother replay analysis. The replay predictive function 240 may operate onalternative metabolic inputs (different from the reconciled metabolicinputs), either in the form of alternative specific inputs or in theform of alternative strategies, to produce a replay prediction in theform of a trajectory of simulated metabolic outcomes from thealternative metabolic inputs along with the credibility of theassociated predictions. The resulting replay predictive function 240 canbe used in a wide variety of applications, including retrospectivetherapy optimization or retrospective insights about therapy. Theassessment of credibility of the replay prediction is directly linked tothe credibility of the reconciled estimated metabolic inputs, both ofwhich enable further features and functions described herein. Additionalapplications and outputs of the replay compiler include basal titration,illustrating the impact of bolus timing vs. meal timing, and validationof AP algorithms, for example.

The prediction engine 250 uses the output 225L of the live inputcompiler 220L operating on live data 212, along with a state estimatorusing estimated model parameters 275, which may be an individualizedphysiological model, and prediction user requirements 253, to producelive input-reconcile predictions 255. The live input-reconcilepredictions 255 operate on candidate present and future metabolic inputsto produce a real time prediction in the form of a predicted trajectoryof metabolic outcomes for the candidate inputs along with thecredibility of the associated predictions. The live input-reconcilepredictions 255 can be used in a wide variety of applications includingcomparing alternative actions for (i) real time decision-making,including selection of the next control step in closed-loop control ofdiabetes, predictive bolus advisors, and decision support, and (ii) forproducing real time insights, such as smart alerts. The assessment ofcredibility of the live input-reconcile predictions 255 is directlylinked to the credibility of the reconciled estimated metabolic inputs,both of which enable further features and functions described herein.

The parameter estimator 270 uses patient biometric and demographicinformation 273 along with the retrospective data 210 and the output225R of the retrospective input compiler 220R to determine and outputestimated model parameters 275 (e.g., of the state estimator, which maybe an individualized physiological model). An individualizedphysiological model is helpful, but not required in implementations. Theparameter estimator 270 is useful in the context of implementations thatutilize an individualized model for estimation but is not criticalrequired.

FIG. 3 is a block diagram of an implementation of a retrospective inputcompiler 220R. Broadly, this approach to combining trusted and untrustedmetabolic inputs can be applied any time data inputs with uncertainaccuracy or reliability are sought to be reconciled. The retrospectiveinput compiler 220R comprises a metabolic input estimator 320, acredibility assessor 310, an input reconciler 330, and a state estimator340.

As described with respect to FIG. 2, retrospective data 210 is input tothe retrospective input compiler 220R. Retrospective data may come in avariety of formats, including measured signals or inputs, trustedmetabolic inputs, untrusted metabolic inputs, and estimated state(s). Inthe retrospective input compiler 220R, the inputs are classified astrusted or untrusted, and various estimates are determined, andestimates of the untrusted inputs in the form of reconciled estimates ofhistorical metabolic inputs are calculated, e.g., taking anunacknowledged estimate of carbohydrates and reconciling with receiveddata.

The measured signals are comprised within the retrospective data 210 andprovided as input to the retrospective input compiler 220R, and moreparticularly to a metabolic input estimator 320. The measured signalsare typically measurements of glucose levels including, for example,real time CGM readings, confidence readings assigned to the CGM values,self-monitoring blood glucose readings (blood glucose meter), and/orretrospectively calibrated or corrected CGM readings and other measuresignals, such as insulin measured by an internal insulin sensor.

Metabolic inputs are comprised within the retrospective data 210 andprovided as input to the retrospective input compiler 220R, and moreparticularly to a metabolic input estimator 320. Metabolic inputs can begenerally thought of in terms of what happened and when (timing andmagnitude). An example may include estimating metabolic state from knownmetabolic inputs recorded by an insulin pump and uncertain metabolicinputs describing a meal recorded by the user.

Trusted metabolic inputs are the known metabolic inputs, which may berecorded directly by an electronic/electromechanical device and/orestimated by a machine. Examples include insulin pumps and connectedinsulin pens that record the insulin injection time. These devicesdirectly measure the action of the pump or syringe that is dispensinginsulin with a high degree of accuracy. Note there can still be faults,like occlusions, that cause uncertain infusion rates. Regarding insulininputs, the systems and methods contemplated herein are not tied to aspecific model for delivery (e.g., pump versus pen).

Untrusted metabolic inputs are uncertain metabolic inputs, which may beentered by the user. Uncertain inputs can be thought of in terms of whathappened and when (e.g., timing and magnitude). An example is a userinput providing a meal's carbohydrate content and meal time that ismanually entered on a phone app. More broadly, it includes any input tothe time series that relies on user entry that is not confirmed by aconnected device, such as insulin dosing with a nonconnected pen orpump. This may include the case of carbohydrates estimated by anotherphone app, e.g., ByteSnap. In principle, untrusted metabolic inputscould also be the unreliable action of insulin due to infusion pump andinfusion site variability. This is the uncertainty around these dynamicinputs to the system that may be reconciled with retrospectivemeasurements (like CGM). The untrusted can refer to inexact timing orcontent of the event data, such as for meal entry. Untrusted metabolicinputs can also include factors like exercise or illness that aredifficult for the user to quantify. There are also untrusted metabolicinputs that result from indirectly measured inputs.

The meal input is defined in terms of time and amount of carbohydrates.User inputs (meal announcements) are typically defined as a singlecarbohydrate event. Some exemplary user-entered meal data that may beuntrusted include: user is estimating the amount of carbs or othernutrient information about a meal, e.g., user may estimate for a burritobut not include chips and salsa eaten while waiting; a meal issimplified to a small-medium-large qualifier; a meal is simplified to anamount of carbohydrates that does not account for the glycemic index;meal response also depends on fat and protein content; user isanticipating when they are going to eat when they are entering a premealbolus; user is prompted to recalling when they ate after the system hasdetected a meal response; and system records a single time for the mealthat spans a period including appetizers, main course, and dessert.

Some examples of untrusted metabolic inputs that result from indirectlymeasured inputs include: meal apps that estimate carbs using databases,barcodes, restaurant photos etc.; meal apps that categorize the upcomingmeal from a library of previous meals; exercise intensity and durationestimated from a fitness tracker (heart rate/accelerometer); and sleepduration estimated from a fitness tracker.

Table 1 shows examples of metabolic inputs with known input anduncertain input.

TABLE 1 Metabolic Input Known Input Uncertain Input ‘Simple’ Meal Manuallogging of User entered time and (time and carb data in a clinical sizeor carb estimate content) context Carb acknowledgement Meal type (Carb/Provided meals Photo tools protein/fat/etc.) (like diet companyNutritional database meal) Insulin injection Connected pen User enteredtime, type and amount Uncertainty of pen priming Insulin pump Pump n/aOral meds n/a User entered/confirmed Glucagon Dual hormone Userinjection pump Exercise Controlled variable Fitness tracker, heart rateSleep Controlled variable Fitness tracker Insulin delivery Pumpocclusion Variable time curves

The last row in Table 1 contemplates including the “unreliable action”of insulin due to infusion pump and infusion site variability. In otherwords, the pump reliably records the plunger moving but due to problemswith the infusion site or catheter this insulin may not be entering thebody. As a result, the amount of insulin pumped would need to bereconciled with the observed (lack of) insulin action, in someimplementations.

Other inputs may include gut and glucose rate of appearance, sensor lag,and could be expanded to general metabolites, for example.

Estimated initial state(s) are data comprised within the retrospectivedata 210 and provided as input to the retrospective input compiler 220R,and more particularly to a metabolic input estimator 320. The estimatedinitial state provides an initial state of the glycemic model, includingglucose levels (blood and other compartments), insulin levels (blood andother compartments), carbohydrate levels (due to previously eaten meal),and metabolic demands (effects of previous exercise and current activitylevel). This may be a vector as it defines these quantities at one pointin time (the initial state).

In some embodiments, one or more model parameters 275 may be provided asinputs to the retrospective input compiler 220R (e.g., to the inputreconciler 330).

The output of the retrospective input compiler 220R comprises (i)reconciled estimated metabolic inputs (including both trusted anduntrusted inputs), (ii) a corresponding estimate of the metabolic state,and (iii) assessments of credibility of the input and state estimates.

More particularly, the metabolic input estimator 320 receives andprocesses the retrospective data 210 and generates (outputs) estimateduntrusted metabolic inputs and disturbance inputs 325.

The metabolic input estimator 320 may use an individual mathematicalmodel that is a compartmental model of the metabolic processes thatproduce or consume glucose in the body. For example, this model hasterms that describe the increase in glucose following meals and theuptake of this glucose into muscles and adipose tissue that isstimulated by insulin. The model is individualized to account forbetween-subject differences in the insulin action and meal metabolismand diabetes (e.g., type 1 versus type 2).

In one implementation, the systems and methods described herein estimatethe time series of uncertain metabolic inputs and the states themselves,which may include estimates unknown/incompletely observed events. Inthis implementation, metabolic input estimation is based on the measuredsignals, past estimated metabolic states and known metabolic inputs,which are extracted to form vectors of measurements, inputs andcorresponding initial state. Uncertain inputs (e.g., reported meals) arenot inputs at this stage. Only what was known in the past and what wasmeasured is inputted. Raw inputs are converted into vectors ofappropriate length, that depends on the use (e.g., real time 6 hoursversus retrospective using an extended day of 36 hours to get a fulldaily cycle and avoid edge effects/boundary conditions). These aremeasured signals. The range of data (time span) depends on theapplication (i.e., the implementation) and may range from minutes tohours to days. The data may then aligned, snapped, interpolated andsmoothed as needed depending on the implementation. Next, the systemuses a linear dynamic model (e.g., without mapping) to determine thesystematic residual, which is the difference between the measure signalsand the model predicted impact of the estimated initial metabolic stateand the known metabolic inputs. The unknown inputs that optimallyexplain the systematic residual are then computed based on the fit ofthe systematic residual and the shape of the estimated unknown inputs(e.g., regularization). For example, the set penalties for the fit,emphasizing (i) high confidence samples, (ii) last samples, (iii) lastrate of change, (iv) important samples (e.g., hypoglycemia orhyperglycemia) and the set regularization penalties to achieve desirableproperties may include (i) smoothness or discreteness of the estimatedunknown input, (ii) allowing/disallowing bias, (iii)allowing/disallowing high rates of change or acceleration (other setconstraints can include specifying non-negativity (e.g., for meals)).This a type of inverse problem that is solved by regularizeddeconvolution. A challenge is constraining the inversion to physicallyreasonable and interpretable values that are reasonably consistent withthe measured results (CGM traces), initial conditions and providedinputs. As such constraints may be imposed, including non-negativemeals, regularization of episodic meals and slowly time-varying insulindifferential to achieve desirable properties, dynamically adjusting theimportance of fitting the data based on quality, for example, may beperformed. From these computations, vectors of both estimated metabolicstate trajectory may be extracted and raw estimated uncertain metabolicinputs are extracted.

The credibility assessor 310 generates an output of credibility 315R(outputs a credibility value). The credibility 315R is derived from thedifference between the raw estimates of the untrusted inputs and what isreported.

The credibility assessor 310 evaluates a plurality of inputs, includingmeasured signals, known metabolic inputs, reported uncertain metabolicinputs, raw estimated metabolic states, uncertain metabolic inputs, andreconciled uncertain metabolic inputs, all of which may be provided intime series.

Credibility based on the measured signals may evaluate continuity (e.g.,the lack of continuity) or completeness of the time series data, and mayinclude one or more of sensor assessed confidence threshold, calibrationevents, max gap size, floating scope, periodic scope, or the like.

Credibility based on the known metabolic inputs and raw estimatedmetabolic states and uncertain metabolic inputs may evaluate expectedbehaviors indicative of incomplete data or lack of unity, and mayinclude one or more of expected correlations between inputs (uncertainor known), expected event counts, floating scope/periodic scope, and thelike.

Credibility based on the reported uncertain metabolic inputs, rawestimated metabolic inputs, uncertain metabolic inputs and reconcileduncertain metabolic inputs may evaluate local variance vs. globalvariance (indicative of unannounced or unreported inputs), discrepancybetween reported and estimated uncertain inputs, pattern matching,floating/periodic scope and the like.

The credibility assessor 310 aggregates the one or more credibilityevaluations described above and provides (outputs) a credibility offinal estimated metabolic state and reconciled estimate inputs, whichmay include the credibility as a time series.

The credibility assessor 310 may determine CGM continuity, quality ofthe fit, total carbs, number of carb events, carbs corresponding to BGartifacts, agreement with user-reported carbs, veracity of insulin data(especially in MDI (metered dose inhaler)), etc.

In some implementations, an aggregated sense of the credibility of datacollected at a particular time of day may be obtained by averagingcredibility scores at that time across multiple days. If the averagevalue of credibility that time is low, then there may be a systematicissue with how the data is being collected. For example, if the patientis using a non-connected pen to bolus meals at work, then this wouldshow up as a high value of insulin at that time of day, with highvariability over time, which would translate into a low averagecredibility score at that time of day. As another example, if thepatient is consistently acknowledging regular meals at times far awayfrom estimated carbs, then this can lead to low credibility scores bothat the time of actual eating and at the time of the acknowledgement ofeating.

The input reconciler 330 reconciles uncertain untrusted user inputs withestimated inputs, wherein the reconciliation is based on one or more ofmeasure signals, trusted metabolic inputs, untrusted metabolic inputsand model parameters. The methods do not necessarily evaluate a penaltyof the estimate of the closeness to the reported, rather they mayevaluate a sigmoidal wave of reported and estimated inputs over time. Insome implementations, the methods may learn the patients' typical errorsover time. The input reconciler 330 outputs reconciled estimates ofmetabolic inputs and disturbances for use in further processing and/ordisplay.

The state estimator 340 provides an estimate of what was actuallyhappening in the system. The process disturbances here are allowed to benonzero (e.g., not zero mean) and not a measurement error. The output ofthe state estimator is an estimate of the states, which can be multiplevectors/matrix.

In one implementation, the state estimator receives the initialmetabolic state (from past state estimates), the (vector of) knownmetabolic inputs, and the (vector of) reconciled uncertain metabolicinputs. Having estimated and reconciled the input time series, all thatremains to compute is the associated state trajectory, which is outputas a final estimated metabolic input vector.

In one exemplary model, the interaction of insulin to glucose clearancewith two differential equations that include different types of insulinused for intensive insulin therapy (e.g., fast and long-acting) anddifferent compartments of equilibration (e.g., liver) is captured. Othermetabolic models could be used in this same framework for prospectiveand retrospective estimators. The tradeoff is between physiologiccompleteness and stability/observability. For example, simple models cancombine details or compartments that are physiologically separate withseveral types of mass transport etc., whereas more complex models canresolve differences between patients or differences in glucose-insulinbehavior over time. In practice, there are limits to the complexity of amodel that can be observed using only CGM data and observational data(e.g., normal daily variation) because more complex models may requireclinical studies with additional measurements like multiple tracers orwell-described inputs such as OGTT (oral glucose tolerance test) ormeals with known composition (fat/carbs/protein). However, the morecomplex model may be useful in solving the issue of inputs based oncorruption.

Credibility determination may be performed here on the estimatedmetabolic state(s) independent of the credibility determination that maybe performed on the reconciled untrusted metabolic inputs, includingcredibility of the reconciled estimated metabolic inputs and credibilityof the estimated metabolic states.

The outputs of the retrospective input compiler 220R include reconciledestimated metabolic inputs which are the untrusted metabolic inputs thathave been estimated and reconciled. The trusted metabolic inputs may beconsidered to be passthrough inputs and may thus be outputted in theiroriginal form in some implementations. It is noted that these inputs andoutputs do not include uncertainty in the model parameters like insulinsensitivity.

Exemplary output of the retrospective input compiler 220R may includetransients in the blood glucose signal that result from differenteffects (signature in BG variability) and a perturbation signal thatdescribes the transients in the signal that vary from oral carbs andother affects, which may be divided as follows: OC (oral carb) mixedmeal postprandial responses (adjusted to account for previous carbs andinsulin delivery); signal explaining low-frequency variation in bloodglucose concentration consistent with changes in insulin sensitivity;and signal explaining aspects of the blood glucose trace that cannototherwise be interpreted as postprandial responses or changes in insulinsensitivity, such as variability due to changes in posture, physicalactivity, or (potentially) to meals that do not fit well the profile ofa “mixed” meal.

An estimated net oral carb effect may also be determined. One meal maybe split into several discrete carb signals. There can be glucose addedfrom endogenous sources like the liver that are modelled as net oralcarbs.

Other behavior or physiology that may be captured include, for example:glycemic consumption during exercise (acts like insulin as it increasesglucose uptake); post-exercise changes in insulin sensitivity; dailyvariation of insulin sensitivity (diurnal variation); differences ininsulin on board curves/insulin curves; and unlogged bolus.

The metabolic state estimates 345R comprise a time series of insulin andglucose levels in the compartments of the model and CGM signal.

A final reconciled meal history includes the time and net carbs. Thedelivered insulin is a passthrough of the retrospective input compiler220R.

Thus, in the retrospective input compiler 220R, estimates of themetabolic state of the patient are constructed from the stream of thetrusted data and now the stream of estimates of the untrusted data(associated with that estimated state trajectory for each period of timebeing estimated) has a credibility assessment (a confidence level thatthe patient ate something and when). This may be performed historicallyfor last month's data, but also on the data newly received data, such aslive data 212 described further herein e.g., with respect to live inputcompiler 220L.

FIG. 4 is a block diagram of an implementation of a live input compiler220L. The live input compiler 220L comprises the same components as theretrospective input compiler 220R, but uses live data 212 as the inputinstead of using retrospective data 210 as the input. Thus, like theretrospective input compiler 220R, the live input compiler 220L alsocomprises the metabolic input estimator 320, the credibility assessor310, the input reconciler 330, and the state estimator 340.

The output fields of the live input compiler 220L are the same as thoseof the retrospective input compiler 220R, except that are based on thelive data 212. As such, the outputs of the live input compiler includecredibility 315L, recorded estimates of metabolic inputs anddisturbances 335L, and metabolic state estimates 345L. In this manner,untrusted pieces of the live data 212 are reconciled based on otheravailable data. For example, the metabolic inputs like carbs from thelast 6 hours can be estimated, and the corresponding states for the last6 hours and credibility for last 6 hours can also be estimated.

With the live input compiler 220L, a patient is interacting with thesystems and methods in real time. Patients do not behave consistentlylike an AP system would and do not always provide accurate data (e.g.,mis-reported carbs either from a counting issues, a timing issue, orboth). One example application could suggest when and/or how much mealappeared to have been consumed, allowing the patient to confirm or deny,or modify the suggested meal information. This enables meal/exercisedetection, as well as plasma glucose prediction. In the example ofprediction of glucose, the systems and methods described herein are ableto predict glucose for the next two hours using data from the last 6hours. Additionally, credibility of the sensor data can be determined(how close to a calibration, is signal bumpy, is sensor out of range)and used in overall carb and insulin credibility measure. Similarly,insulin data credibility may be determined (missing basal data,unexplained drops in glucose concentration (unacknowledged bolus),etc.). The systems and methods allows for intelligent interaction anddecision making knowing the reconciliation of the detected data with thereported data.

When dealing with live data, because of not having the benefit of theknowledge of future it is important to pay particular attention to themost recent value and its slope. E.g., require estimator to findagreement between the most recent points (last two) by weighting themost recent data more heavily. In one implementation, the inputreconciler vector extracts the reported uncertain metabolic inputs forreal time applications, wherein the resulting vector is such that thelast entry corresponds to the current time. The extracted vector(s), incombination with vectors of raw estimated uncertain metabolic inputs,are combined in a function based on time-relevance and/or relativeconfidence as described below.

Example 1 (for live predictor): weighting is applied base ontime-relevance, wherein recent reported inputs are most heavilyweighted, long-time past reported inputs are lightly weighted and recentraw estimated inputs (if any) are lightly weighted. Because it requiresfuture data.

Example 2 (applies to live or retrospective): weighting is applied basedon relative confidence of the reported and estimated untrusted inputs,wherein the confidence is based on a user/system rating and/or amodel-based confidence of the estimated inputs.

In one exemplary application, the systems and methods estimatecarbohydrate intake independent of user input. With patients that treatdiabetes using multiple daily injections (without a smart pen), datasuggests this as the safest assumption. The systems and methods considerthe situation when a patient reports a carbohydrate estimation that doesnot agree with the estimated carbohydrate independent of user input.Because the systems and methods cannot take both estimated and reportedcarbohydrate estimates to be true, the process of reconciliation isuseful. Upon reconciliation, the systems and methods express of theresult of reconciliation as a new pair of reconciled estimated inputs.

FIG. 5 is a block diagram an implementation of a replay compiler 230.The replay compiler 230 comprises an input classifier 510 and a replayercore 520. The replayer core 520 comprises an input modifier 523 anddynamic equations 525. The replay compiler 230 performs a replay ofglucose traces by modifying inputs to determine an impact of themodified input. The replay compiler 230 provides a machine for assessingBG, insulin, meal, and behavioral outcomes at different scopes(individual/population) with different masks (closed-loop, sleep,credible, etc.). The systems and methods take any non-optimalintervention in diabetes, simulates scenarios to determine an optimalintervention and quantifies effect of optimal intervention—either as aCGM trace or glycemic effect of optimal vs. non-optimal.

The inputs to the replay compiler 230 are the retrospective compiledinputs (i.e., the output 225R of the retrospective input compiler 220R)including credibility 315R, reconciled estimates of metabolic inputs anddisturbances 335R, and metabolic state estimates 345R (e.g., estimatedmetabolic states, final reconciled estimated metabolic inputs, knownmetabolic inputs and alternative metabolic inputs (specific inputs orstrategies for the duration of the time series)). In someimplementations, the inputs include all of the metabolic inputs (trustedand reconciled estimates of untrusted) as a time series and credibility.

The input classifier 510 receives the reconciled estimates of metabolicinputs and disturbances as input and classifies each data as amodifiable exogenous metabolic input 512 or an invariant exogenous input515.

In some implementations, a trusted piece of data (e.g., insulin) may bemodified. In other implementations, a trusted piece of data and anuntrusted piece of data (e.g., meal data) may be modified. In otherimplementations, all the inputs may be modified.

A variety of scenarios may be contemplated with the replay compiler 230:A) all untrusted reconciled data is modified in the replay function; B)some but not all untrusted reconciled data is modified in the replayfunction; C) some trusted data is modified in the replay function; andD) combinations of B) and C). In general, the replay compiler 230modifies at least some data and runs at least one simulation. Forexample, it may be a trusted piece of data, like insulin. Sometimes, itis both a trusted piece of data and an untrusted piece of data, likeboth insulin and meals (e.g., replacing the reconciled bolusable carbswith some other scripted meal behavior, leaving the signature of BGvariability as the only thing that is not modified). In an exemplaryembodiment, all inputs are modified.

The replayer core 520 comprises the input modifier 523 and dynamicequations 525. The input modifier 523 receives the modifiable exogenousmetabolic inputs 512 and a specification of rules for modifyinghistorical inputs 550 (referred to also as a specification of rules550).

The inputs 512 are thus modified at the input modifier 523 using thespecification of rules 523. The specification of rules 523 are “what if”scenarios that are to be tested to determine an outcome based on amodification of an input. Rules may be selected by the user individuallyand/or based on preset scenarios. Some rules that may be specifiedcompare the following: Conversion of MDI to CSII (continuoussubcutaneous insulin infusion) or vice versa, long-acting dosage/timing,basal rate profiles, recognition/removal of hypoglycemia treatments inthe historical data, revising of historical boluses, revising of bolusdoes parameters, insertion of prospective hypoglycemia treatments attimes where alternative insulin input create new instances ofhypoglycemia, replacement of instances of historical meals with aprospective model, replacement of historical acknowledgements of carbswith a prospective acknowledgement model (e.g., acknowledging carbs attimes close to estimated carbs).

Additional specification of rules may be designed to process andevaluate: exercise and/or how to optimize treatment around exercise;treatments to include rescue carbs (e.g., amount required); treatmentsto include other meal bolusing strategies (e.g., split, delayed, andextended boluses); and type 2 treatments including oral medications,etc.

Specification of rules may be provided directly by the patient, based ona call of a particular pre-programmed function, based on a userinterface, such as reporting and analysis software and/or otherinterfaces that allow the user to select a particular scenario (“what ifI bolused earlier”), ask a specific questions (“what if I were on pumptherapy”) and/or modify specific inputs (“what if I take two additionalunits of insulin when I bolus”), or the like, as may be appreciated byone skilled in the art. The selections may be real time or retrospectiveand may be presented at a variety of levels of granularity.

The output of the input modifier 523 are provided to the dynamicequations 525 as input along with the invariant exogenous inputs 515,the metabolic state estimates, and the model parameters 275.

In an implementation, the dynamic equations may use an individualmathematical model that is a compartmental model of the metabolicprocesses that produce or consume glucose in the body. For example, thismodel has terms that describe the increase in glucose following mealsand the uptake of this glucose into muscles and adipose tissue that isstimulated by insulin. The model is individualized to account forbetween-subject differences in the insulin action and meal metabolismand diabetes.

The dynamic equations 525 perform replay on the inputs. Replay runsmodel-based estimation using any known model-based approach that takesinto account meal and/or insulin parameters. For example, the model mayuse standard mixed meal that is a typical combination of carbs, proteinand fat. However, other meal signatures may be used, e.g., highcarb/glycemic meal and/or low carb/glycemic meal, or even a combinationof various types of meals. Some implementations may add long-actingmeals versus short-acting meals based on composition and glycemic index,etc. This would run as part of the reconciliation. If the meal action issignificantly different from the standard meal, then it may be explainedin a way that is less physiologic accurate. For example, 30 g of carbsfrom pizza would be estimated by a 30 g initial meal followed by two 10g meals.

In an implementation, the estimation of metabolic states are performedfor the duration of the input time series and play forward theindividualized mathematical model to the end of the input time series.

The model parameters 275 are an optional estimate useful, but notessential, as a feedback input to make the parameters moreindividualized for the patient.

Replay credibility 580 is determined by the replay compiler and output.The replay compiler 230 identifies and outputs credible instances ofparticular scenarios (samples) in the replay analysis. This may beperformed by scoring each sample (e.g., each replay analysis result)with a credibility score. For example, identifying credible instances ofsuccessfully avoiding hypoglycemia; failing to avoid hypoglycemia,and/or skipped or significantly delayed meal boluses. The averagecredibility score of samples in a data set in replay analysis gives anoverall sense of the significance/believability of the replay result,which may be useful in interpreting the results.

A comparator may be comprised within the replay compiler 230 to comparethe various time series from the dynamic equations 525 based on thecredibility of the data (weighted so that less credible data is ignoredor has low weighting). Another example if the signatures of BGvariability are to erratic, data may become non-credible during thattime period. One skilled in the art appreciates that there are many waysto recognize the patient data is inconsistent with the model.

In an implementation, BG outcome metrics are assessed in replayed timeseries based one more or more of: sample means, sample variance,time-in-range, episodes of high/low BG, low blood glucose risk, highblood glucose risk, overall risk. Unlike a conventional technique thatcomputes average blood glucose by equally weighing all samples, here thecredibility score of each sample is used to determine the weight thateach sample has in the average.

The output of the dynamic equations 525 comprises replay prediction timeseries 570. The output (the time series 570) may be provided to theinput modifier 523 for subsequent use and may include replay simulatedmetabolic states resulting from alternative inputs with credibilityscores. The output may include the simulated time series, the result ofthe compared time series (worst/best/actual), a recommendation based onthe compared time series, and any other data processed by the system(e.g., credibility score).

In some embodiments, the replay compiler 230 functional output could bea reproduced (simulated) CGM trace that the patient actuallyexperienced. The replay compiler 230 is a function that when run onhistorical CGM reproduces the trace, in which case the CGM trace wouldbe a smoothed version of the CGM trace without the sensor imprecision,and including additional information for example can reproduceadditional correlative data (e.g., meals) not provided by patient.

In therapy optimization in DSS (decision support system) or AP usecases, the replay compiler 230 could optimize therapies, such as totaldaily basal, wherein the input would be parameter to be optimized(actual basal insulin), output would be optimized version of that input(optimal basal insulin). Replay simulates optimal prescriptionamount/time of parameter (total daily basal in one example).

In patient education use cases, a dynamic report (retrospective or realtime) may be generated that allows a patient to highlight or dragthrough scenarios and see the results of the “what if scenarios”returned from the replay compiler 230. For example, a slider bar in agraphical user interface may allow a patient (or other user) to slidethings around and then see the impact resulting from the replay analysis(more carbs, less carbs, higher glycemic, lower glycemic, earlier bolus,later bolus, more insulin, less insulin, etc.).

In some embodiments, providing an output of the average credibilityscore of samples in a data set in replay analysis gives an overall senseof the significance/believability of the replay result.

In some embodiments, a risk stratification tool for health careprofessionals may be provided as output that identifies patients by aparticular category or need, e.g., patients with least premeal bolusingcompliance, and may include the potential benefits of therapyadjustments.

In some embodiments, output may highlight/prioritize the most impactfulpotential changes in a reporting interface (e.g., changing insulintiming versus bolus amounts or highlight best meals).

In some embodiments, output may trigger coaching comments and discussionpoints via coaching call or chatbot prompts.

FIG. 6 is a block diagram of an implementation of a prediction engine250. The prediction engine 250 receives the retrospective compiledinputs 225R and the live compiled inputs 225L as inputs, along with themodel parameters 275 and the prediction user requirements 253, andoutputs real time predictions 255.

The initial state of the prediction engine 250 would describe the amountof insulin and carbohydrates that are already in the body and acting onthe glucose level. With no additional action, the prediction engine 250would predict future metabolic states such as a glucose excursion from aprevious meal as well as hypoglycemic events. Prediction isextrapolation of reconciliation from the input compiler 220. In otherwords, prediction is also responsive to historic data as well asreconciled data.

The prediction engine 250 comprises an input extrapolator 610, an inputfilter 620, a metabolic state estimator 630, an output filter 640, andan initial condition extractor 650.

The input extrapolator 610 uses the prediction user requirements 253,the credibility and the reconciled estimates of metabolic inputs anddisturbances from the retrospective compiled inputs 225R, and thecredibility and the reconciled estimates of metabolic inputs anddisturbances from the live compiled inputs 225L to performextrapolation. The extrapolated data is provided from the inputextrapolator 610 to the input filter 620.

The input extrapolator 610 extrapolates the input time series to accountfor (1) additional information about the future available in real time(e.g., expected meals, exercise, etc.) and (2) signatures of BGvariability.

The input extrapolator 610 may use the retrospective compiled inputs225R to make inferences based on historical data, e.g., use recent pastof signatures of BG variability (i.e., disturbances) and effect ofhistorical signatures of BG variability. Signatures of BG variabilitymay be used to interpret data as it goes farther into the predictionhorizon.

The prediction engine 250 may project disturbances (signature of BGvariability) which shows the trend of inaccuracies in the data resultingfrom differences in reconciled data. A disturbance signal is a result ofthe reconciliation process, and may be considered to be an estimatedunknown signal. For example, a disturbance could result from circadianrhythms, exercise trends, etc. The accuracy of prediction depends ondifferent assumptions about the future based on the nature of thedisturbance.

The input filter 620 filters the extrapolated data with the predictionuser requirements 253 and provides its output to the metabolic stateestimator 630.

Depending on the implementation, the input filter 620 is optional,however it may be useful when other filtering or smoothing has not beenapplied to one or more of the inputs. The input filter 620 filters orsmooths the extrapolated input time series to prevent jitter inpredicted trajectories to (1) sensor noise and (2) rapidly evolvingunderstanding of recent untrusted inputs. In some implementations, theinput filter 620 uses a low pass filter to minimize jitter in thepredicted trajectories in successive updates.

The initial condition extractor 650 extracts data from the metabolicstate estimates of the live compiled inputs 225L and provides theextracted data to the metabolic state estimator 630.

The metabolic state estimator 630 receives the filtered data and theextracted data as inputs along with the prediction user requirements 253and the model parameters 275. The metabolic state estimator 630processes these inputs and provides output to the output filter 640.

The metabolic state estimator 630 receives the (optionally filtered)extrapolated inputs(s), the extracted initial condition and the modelparameters to the extent an individualized physiological model is beingused by the estimator. A variety of estimators may be useful. In oneembodiment, the metabolic state estimator 630 performs an open-loopestimate of metabolic states into the future from the best estimates ofthe metabolic state vector at the beginning of the time series, playingforward the individualized physiological model all the way to the end ofthe prediction horizon.

In some implementations, the metabolic state estimator 630 may use anindividual mathematical model, which is a compartmental model ofmetabolic processes that produce or consume glucose. For example, thismodel has terms that describe the increase in glucose following mealsand the uptake of this glucose into muscles and adipose tissue that isstimulated by insulin.

The output filter 640 filters the output from the metabolic stateestimator 630 along with the prediction user requirements 253 and thecredibility and the reconciled estimates of metabolic inputs anddisturbances from the live compiled inputs 225L and provides its outputas the real time predictions 255. The output filter 640 can be used toconstrain the real time predictions 255 depending on the live compiledinputs 225R.

The output filter 640 is an output module that renders a predictedoutput time series (i.e., the real time predictions) to (1) allowdramatic changes in predicted trajectories only when there arerecognizable and significant changes in reconciled inputs and/or (2)filter/smooths or otherwise prevent jitter in the predicted trajectoriesdue to sensor noise.

The real time predictions 255 (i.e., live predictions) may be apredictive profile of future BG (e.g., in vector form) and can be usedto inform decision making going forward. For example, a prediction mightshow upcoming hypoglycemia, and the prediction may then be used to alertand/or cause a patient to ingest fast acting glucose tablets.Reconciliation and prediction as described herein allow for moreresponsiveness to patient behavior change and therefore betterprediction of metabolic state.

In some implementations, the real time predictions 255 are a vector ofpredicted metabolic state. The stability of the resulting predictionremains stable until there are markers of an impending state changes(e.g., meals and insulin allow a more dynamic output). Patient providedinput and detected input leads to credible changes when the patient isexpecting it.

In some implementations, the prediction engine 250 may apply conditionalweighting to data, wherein the historical data may be weighted accordingto (1) time of day, (2) features of the current estimated state, and (3)side information. The conditional weighting is based on final estimatedmetabolic states, a database of past metabolic inputs (trusted anduntrusted) and side information in some implementations.

Signature of BG variability into the future is a key differentiator inthe prediction engine 250. Additional key advantages, which may be usedalone or in combination, include: reconciled meals; input extrapolation(e.g., meals set to zero); and signature of BG variability informed bytime day from retrospective models and daily trend. Typically, forpredictor in real time this is rerun for the last 6 hours of datastarting point.

Weighting of the signature of BG variability is dependent on thedeference to the patient and depending on available reported vs.reconciled data and the credibility thereof (e.g., depends on time sinceevent).

The systems and methods described herein have a trade-off of the timedomain predictions, wherein more weight is given to the reconciledinputs to the most immediate value. The conditional weighting allowsthese models to be tuned to specific variations.

In some implementations, credibility is calculated for the predictedstate based on the credibility of the inputs, including raw inputs andreconciled inputs. Uses of credibility in real time prediction withreconciliation include: (1) confidence of medical actions determined viareconciled projection, namely, if the prevailing credibility score islow (e.g., due to low confidence in recent CGM samples, or to evidenceof unacknowledged meals and/or boluses), then corresponding resultingreconciled projection may be not credible, and (2) determination of theneed to wait before offering advice based on reconciled projection,namely, if the prevailing credibility score is low, then the patient maybe advised to wait a while longer before a recommendation is rendered.

FIG. 7 is a block diagram of an implementation of a parameter estimator270. The parameter estimator 270 is configured to perform parameteroptimization. The parameters are tuned only on reconciled, credibledata. Parameter optimization is applied to get the best settings formetabolic model parameters based on a retrospective data set. Over timethe predictor can be run retrospectively to improve prediction. Themodel is optimized to give the best predictive model performance.Parameter estimation is optional and depends on the type of estimationused in the previous blocks and what type of model is used for thatestimation.

The parameter estimator 270 is built to make the optional individualizedphysiological model used by the prediction engine as accurate aspossible by optimizing the estimated model parameters 275 that areprovided as output. The goal is to estimate physiological parameters ofthe patients, generic application, e.g., insulin sensitivity, absorblipro (medication) absorption rate, any physiological, etc.

In practice, the optimization uses retrospective data, runs thepredictor on that data, builds the prediction engine, apples toretrospective data as if it was live and looks to see how accurately itproduces predictions of the retrospective trace, tuning of the parameteris based on accuracy of simulated predictions

The parameter estimator 270 receives the retrospective compiled inputs225R and the retrospective data 210 data as inputs, along with patientbiometric and demographic information 273, and outputs model parameters275.

The parameter estimator 270 comprises a candidate parameter generator710, a live predictor instance 720 (which comprises a live inputcompiler and prediction engine), and a credibility-informed errorassessor 730.

The candidate parameter generator 710 generates candidate modelparameters 715.

The live predictor instance 720 uses the candidate model parameters 715,the retrospective data 210 (treating the retrospective data 210 as if itwere live data), and the reconciled estimates of metabolic inputs anddisturbances of the retrospective data 225R, and provides its output tothe credibility-informed error assessor 730.

The credibility-informed error assessor 730 receives the output of thelive predictor instance 720 and uses this data along with thecredibility of the retrospective data 225R and the measured signals ofthe retrospective data 210 to generate output that is provided to thecandidate parameter generator 710 for subsequent use in determining themodel parameters 275.

In an implementation, the reference glucose concentration and theinsulin sensitivity for each subject is tuned to the optimized value ofa list of possible values. The predictor may run over 30 days of data(e.g., insulin, CGM and meal, etc.) and determine the best predictor for1 hour out.

FIG. 8 is an operational flow of an implementation of a method 800 forreconciling data. The method 800 may be performed by the platform 200for example. Aspects of the method 800 may be performed by the inputcompiler 220 in some implementations.

At 810, untrusted data pertaining to a subject is received at an inputestimator, such as the metabolic input estimator 320 of theretrospective input compiler 220R or the metabolic input estimator 320of the live input compiler 220L. The untrusted data may be comprisedwithin retrospective data, such as the retrospective data 210, or livedata, such as the live data 212. The untrusted data comprises at leastone of timing of insulin, amount of insulin, meal data, or activitydata, wherein the untrusted data is untrusted because of behavioralanomalies or human error in at least one of timing, amount, estimation,or entry.

At 820, trusted data pertaining to the subject is received at the inputestimator. The trusted data may be comprised within retrospective data,such as the retrospective data 210, or live data, such as the live data212. The trusted data comprises at least one of CGM data, insulin pumpdata, computer generated data, computer generated models, or anindividualized model that describes the glucose and insulin dynamics ofthe subject.

At 830, the untrusted data is reconciled using the trusted data. Theinput reconciler may perform the reconciliation of the untrusted datausing the trusted data. In particular, (1) after the input estimatoruses the trusted inputs, along with the mathematical model, to estimatevalues for the untrusted inputs, (2) the untrusted input data are fusedwith the estimated untrusted inputs to produce a final reconcileduntrusted data set. The untrusted inputs and estimated untrusted inputscan be fused in different ways depending on the application context andtemporal scope. In some cases, such as when the estimated untrustedinputs are estimated with low error covariance, or when the estimatedinputs have proven to accurately predict the blood glucose over time, orwhen the untrusted data source has proven to be completelyuntrustworthy, the reconciled untrusted data can be derived exclusivelyfrom the estimated inputs independent of the untrusted data. In othercases, when the mathematical model and/or the estimated inputs fail tobe predictive of blood glucose over time, or when the untrusted sourceof data is able to demonstrate accuracy by independent means, thereconciled untrusted data can be derived exclusively from the untrustedinputs themselves. In live application contexts (non-retrospectiveapplications), or when additional data are required to make adetermination of whether the current estimated untrusted inputs are morereliable than the untrusted inputs themselves, then the reconcileduntrusted data can be computed as a blend of the untrusted inputs andthe estimated untrusted inputs, where (1) for the recent past thereconciled result defers to the untrusted data (because more data isneeded to refute it), (2) for the distant past the reconciled resultdefers to estimated untrusted inputs, and (3) in the transition regionbetween recent and distant past, the reconciled value is computed as aweighted average of the untrusted input data and the estimated untrustedinput data depending on the proximity to the current time. Alternativesto the weighted average include (1) probabilistically selecting eitherthe untrusted input or the estimated untrusted input based on theperceived reliability of the of the untrusted or estimated untrusteddata or (2) choosing the untrusted input or estimated untrusted input tomaximize a classification objective, e.g., maximum likelihood or maximuma posteriori probability.

At 840, the reconciled untrusted data is outputted, e.g., from the inputcompiler 220.

FIG. 9 is an operational flow of another implementation of a method 900for reconciling data. The method 900 may be performed by the platform200 for example. Aspects of the method 900 may be performed by the inputcompiler 220 in some implementations.

At 910, untrusted data pertaining to a subject is received, at an inputestimator, such as the metabolic input estimator 320 of theretrospective input compiler 220R or the metabolic input estimator 320of the live input compiler 220L. The untrusted data may be comprisedwithin retrospective data, such as the retrospective data 210, or livedata, such as the live data 212. The untrusted data comprises userentered data comprising at least one of insulin data, meal data, oractivity data.

At 920, the untrusted data is reconciled using trusted data pertainingto the subject. The trusted data may be comprised within retrospectivedata, such as the retrospective data 210, or live data, such as the livedata 212. The trusted data comprises computer generated data. Thereconciliation may be performed using an input reconciler. Inparticular, (1) after the input estimator uses the trusted inputs, alongwith the mathematical model, to estimate values for the untrustedinputs, (2) the untrusted input data are fused with the estimateduntrusted inputs to produce a final reconciled untrusted data set. Theuntrusted inputs and estimated untrusted inputs can be fused indifferent ways depending on the application context and temporal scope.In some cases, such as when the estimated untrusted inputs are estimatedwith low error covariance, or when the estimated inputs have proven toaccurately predict the blood glucose over time, or when the untrusteddata source has proven to be completely untrustworthy, the reconcileduntrusted data can be derived exclusively from the estimated inputsindependent of the untrusted data. In other cases, when the mathematicalmodel and/or the estimated inputs fail to be predictive of blood glucoseover time, or when the untrusted source of data is able to demonstrateaccuracy by independent means, the reconciled untrusted data can bederived exclusively from the untrusted inputs themselves. In liveapplication contexts (non-retrospective applications), or whenadditional data are required to make a determination of whether thecurrent estimated untrusted inputs are more reliable than the untrustedinputs themselves, then the reconciled untrusted data can be computed asa blend of the untrusted inputs and the estimated untrusted inputs,where (1) for the recent past the reconciled result defers to theuntrusted data (because more data is needed to refute it), (2) for thedistant past the reconciled result defers to estimated untrusted inputs,and (3) in the transition region between recent and distant past, thereconciled value is computed as a weighted average of the untrustedinput data and the estimated untrusted input data depending on theproximity to the current time. Alternatives to the weighted averageinclude (1) probabilistically selecting either the untrusted input orthe estimated untrusted input based on the perceived reliability of theof the untrusted or estimated untrusted data or (2) choosing theuntrusted input or estimated untrusted input to maximize aclassification objective, e.g., maximum likelihood or maximum aposteriori probability.

FIG. 10 is an operational flow of an implementation of a method 1000 fordetermining the credibility of data. The method 1000 may be performed bythe platform 200 for example. Aspects of the method 1000 may beperformed by the input compiler 220 in some implementations.

At 1010, untrusted data pertaining to a subject is received, e.g., at aninput estimator, such as the metabolic input estimator 320 of theretrospective input compiler 220R or the metabolic input estimator 320of the live input compiler 220L. The untrusted data may be comprisedwithin retrospective data, such as the retrospective data 210, or livedata, such as the live data 212. The untrusted data comprises userentered data comprising at least one of insulin data, meal data, oractivity data.

At 1020, a credibility of the untrusted data is determined. Thecredibility may be determined by a credibility assessor, such as thecredibility assessor 310 of the retrospective input compiler 220R or thecredibility assessor 310 of the live input compiler 220L. Credibility ofthe untrusted data is assessed from characteristics of the untrusteddata alone at one or more time scales. In particular, failure toacknowledge meals and/or insulin and/or physical activity over a periodof time can be interpreted as incomplete data rendering the whole timeperiod as not credible, e.g., with a credibility value of zero.Similarly, other data artifacts, such as double entries or unusuallylarge (or small) insulin doses and/or acknowledged amounts of carbs orphysical activity over a period time can be interpreted asnon-physiological or behaviorally unlikely, again rendering the timeperiod as not credible. Similarly, transient inaccuracy of generallytrusted inputs can cause them to be treated temporarily as untrustedinputs, e.g., temporary non availability of sensor readings or temporaryout-of-range indications from the sensor, again causing the associatedperiods of time as not credible.

At 1030, trusted data is received at the credibility assessor. Thetrusted data may be comprised within retrospective data, such as theretrospective data 210, or live data, such as the live data 212.

At 1040, the credibility of the untrusted data is updated using thetrusted data. The updating may be performed by the credibility assessor.Credibility of the untrusted data can be assessed based on the extent towhich it agrees with the estimated untrusted input data at one or moretime scales. Specifically, when the underlying model has proven to bepredictive of blood glucose concentration over time and when theuntrusted inputs for a period of time differ from the estimateduntrusted inputs, then the untrusted data can be assigned a low level ofcredibility for that period of time, e.g., closer to zero than one.Independently, a credibility value can be assigned to the reconcileduntrusted inputs based on how the reconciliation is achieved. Forexample, if the model has proven to be highly predictive of bloodglucose over time, the estimated untrusted inputs are highly consistentwith the trusted data, and when the reconciled untrusted data iscomputed to be equal or very close to the estimated untrusted data, thenthe reconciled untrusted data can be assigned a high value ofcredibility, e.g., close to one, even when the corresponded untrusteddata is not credible.

FIG. 11 is an operational flow of another implementation of a method1100 for determining the credibility of data. The method 1100 may beperformed by the platform 200 for example. Aspects of the method 1100may be performed by the input compiler 220 in some implementations.

At 1110, first untrusted data pertaining to a subject is received, e.g.,at an input estimator, such as the metabolic input estimator 320 of theretrospective input compiler 220R or the metabolic input estimator 320of the live input compiler 220L. The first untrusted data may becomprised within retrospective data, such as the retrospective data 210,or live data, such as the live data 212. The untrusted data comprisesuser entered data comprising at least one of insulin data, meal data, oractivity data.

At 1120, a credibility of the first untrusted data is determined at thecredibility assessor, such as the credibility assessor 310 of theretrospective input compiler 220R or the credibility assessor 310 of thelive input compiler 220L. Credibility of the untrusted data is assessedfrom characteristics of the untrusted data alone at one or more timescales. In particular, failure to acknowledge meals and/or insulinand/or physical activity over a period of time can be interpreted asincomplete data rendering the whole time period as not credible, e.g.,with a credibility value of zero. Similarly, other data artifacts, suchas double entries or unusually large (or small) insulin doses and/oracknowledged amounts of carbs or physical activity over a period timecan be interpreted as non-physiological or behaviorally unlikely, againrendering the time period as not credible. Similarly, transientinaccuracy of generally trusted inputs can cause them to be treatedtemporarily as untrusted inputs, e.g., temporary non availability ofsensor readings or temporary out-of-range indications from the sensor,again causing the associated periods of time as not credible.

At 1130, second untrusted data pertaining to the subject is received,e.g., at the input estimator, such as the metabolic input estimator 320of the retrospective input compiler 220R or the metabolic inputestimator 320 of the live input compiler 220L. The second untrusted datamay be comprised within retrospective data, such as the retrospectivedata 210, or live data, such as the live data 212.

At 1140, a credibility of the second untrusted data is determined at thecredibility assessor, such as the credibility assessor 310 of theretrospective input compiler 220R or the credibility assessor 310 of thelive input compiler 220L.

At 1150, the credibility of the first untrusted data is updated usingthe second untrusted data and/or the credibility of the second untrusteddata, depending on the implementation. The updating may be performed atthe credibility assessor 310.

At 1160, trusted data is received at the credibility assessor 310. Thetrusted data may be comprised within retrospective data, such as theretrospective data 210, or live data, such as the live data 212.

At 1170, the credibility of the first untrusted data and the seconduntrusted data is updated using the trusted data. The updating may beperformed by the credibility assessor. Credibility of the untrusted datacan be assessed based on the extent to which it agrees with theestimated untrusted input data at one or more time scales. Specifically,when the underlying model has proven to be predictive of blood glucoseconcentration over time and when the untrusted inputs for a period oftime differ from the estimated untrusted inputs, then the untrusted datacan be assigned a low level of credibility for that period of time,e.g., closer to zero than one. Independently, a credibility value can beassigned to the reconciled untrusted inputs based on how thereconciliation is achieved. For example, if the model has proven to behighly predictive of blood glucose over time, the estimated untrustedinputs are highly consistent with the trusted data, and when thereconciled untrusted data is computed to be equal or very close to theestimated untrusted data, then the reconciled untrusted data can beassigned a high value of credibility, e.g., close to one, even when thecorresponded untrusted data is not credible.

FIG. 12 is an operational flow of an implementation of a method 1200 forusing untrusted data to provide output based on glycemic effects. Themethod 1200 may be performed by the platform 200 for example.

At 1210, data over a time period is predicted for a subject, e.g., bythe prediction engine 250. In some implementations, (1) the initialcondition (corresponding the state of the system in the past), thetrusted inputs from that time in the past, and the reconciled untrustedinputs from that time in the past are used as inputs to the underlyingmathematical model producing an estimate of the patient's currentmetabolic state and (2) accounting for expected future inputs (e.g.,assumed insulin dosing, physical activity, and/or eating behavior), themathematical model is used to predict future metabolic states of thepatient including future blood glucose. Further features and details aredescribed herein with respect to FIG. 6, for example.

At 1220, untrusted data directed to management of diabetes is receivede.g., at an input estimator, such as the metabolic input estimator 320of the retrospective input compiler 220R or the metabolic inputestimator 320 of the live input compiler 220L. The untrusted data may becomprised within retrospective data, such as the retrospective data 210,or live data, such as the live data 212.

At 1230, a plurality of predictive data traces are simulated over thetime period, e.g., by the replay compiler 230. A spectrum of possiblevariances of the untrusted data is used.

At 1240, the simulated predictive data traces are compared to thepredicted data to identify glycemic effects, by the replay compiler 230.

At 1250, a visualization and/or a recommendation based on the glycemiceffects are generated and outputted, by the replay compiler.

FIG. 13 is an operational flow of an implementation of a method 1300 forusing replay prediction. The method 1300 may be performed by theplatform 200 for example. Aspects of the method 1300 may be performed bythe replay compiler 230 in some implementations.

At 1310, estimated metabolic states, reconciled estimated metabolicinputs, known metabolic inputs, and alternative metabolic inputs arereceived at the replay compiler 230.

At 1320, at the replay compiler 230, replay prediction is performedusing the estimated metabolic states, the reconciled estimated metabolicinputs, the known metabolic inputs, and the alternative metabolicinputs. In some implementations, after specifying which historicalinputs are modifiable (those that are either wholly new or are evaluateddynamically as a function of the newly predicted metabolic state of thepatient) and which inputs are invariant exogenous inputs, the underlyingmathematical model (as represented by the dynamic equations) is used toiteratively predict what metabolic states would have been experienced bythe patient due to the modified inputs over some part of (or all of) thetime period described by the retrospective data. The credibility of theretrospectively predicted estimates of the patient's metabolic state isdetermined from the credibility of the corresponding untrustedretrospective data. Further features and details are described hereinwith respect to FIG. 5, for example.

At 1330, replay simulated metabolic states based on the replayprediction are outputted by the replay compiler 230.

FIG. 14 is an operational flow of an implementation of a method 1400 forusing real time prediction. The method 1400 may be performed by theplatform 200 for example. Aspects of the method 1400 may be performed bythe prediction engine 250 in some implementations.

At 1410, alternative metabolic inputs, reconciled estimated metabolicinputs, known metabolic inputs, and final estimated metabolic inputs arereceived, e.g., at the prediction engine 250.

At 1420, at the prediction engine 250, real time prediction is performedusing the alternative metabolic inputs, the reconciled estimatedmetabolic inputs, the known metabolic inputs, and the final estimatedmetabolic inputs.

At 1430, predicted metabolic states based on the real time predictionare outputted by the replay engine 250.

FIG. 15 shows an exemplary computing environment in which exampleembodiments and aspects may be implemented. The computing deviceenvironment is only one example of a suitable computing environment andis not intended to suggest any limitation as to the scope of use orfunctionality.

Numerous other general purpose or special purpose computing devicesenvironments or configurations may be used. Examples of well-knowncomputing devices, environments, and/or configurations that may besuitable for use include, but are not limited to, personal computers,server computers, handheld or laptop devices, multiprocessor systems,microprocessor-based systems, network personal computers (PCs),minicomputers, mainframe computers, embedded systems, distributedcomputing environments that include any of the above systems or devices,and the like.

Computer-executable instructions, such as program modules, beingexecuted by a computer may be used. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data types.Distributed computing environments may be used where tasks are performedby remote processing devices that are linked through a communicationsnetwork or other data transmission medium. In a distributed computingenvironment, program modules and other data may be located in both localand remote computer storage media including memory storage devices.

With reference to FIG. 15, an exemplary system for implementing aspectsdescribed herein includes a computing device, such as computing device1500. In its most basic configuration, computing device 1500 typicallyincludes at least one processing unit 1502 and memory 1504. Depending onthe exact configuration and type of computing device, memory 1504 may bevolatile (such as random access memory (RAM)), non-volatile (such asread-only memory (ROM), flash memory, etc.), or some combination of thetwo. This most basic configuration is illustrated in FIG. 15 by dashedline 1506.

Computing device 1500 may have additional features/functionality. Forexample, computing device 1500 may include additional storage (removableand/or non-removable) including, but not limited to, magnetic or opticaldisks or tape. Such additional storage is illustrated in FIG. 15 byremovable storage 1508 and non-removable storage 1510.

Computing device 1500 typically includes a variety of computer readablemedia. Computer readable media can be any available media that can beaccessed by the device 1500 and includes both volatile and non-volatilemedia, removable and non-removable media.

Computer storage media include volatile and non-volatile, and removableand non-removable media implemented in any method or technology forstorage of information such as computer readable instructions, datastructures, program modules or other data. Memory 1504, removablestorage 1508, and non-removable storage 1510 are all examples ofcomputer storage media. Computer storage media include, but are notlimited to, RAM, ROM, electrically erasable program read-only memory(EEPROM), flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computing device 1500. Any such computerstorage media may be part of computing device 1500.

Computing device 1500 may contain communication connection(s) 1512 thatallow the device to communicate with other devices. Computing device1500 may also have input device(s) 1514 such as a keyboard, mouse, pen,voice input device, touch input device, etc. Output device(s) 1516 suchas a display, speakers, printer, etc. may also be included. All thesedevices are well known in the art and need not be discussed at lengthhere.

In an implementation, a method comprises receiving, at an inputestimator, untrusted data pertaining to a subject; receiving, at theinput estimator, trusted data pertaining to the subject; reconciling,using an input reconciler, the untrusted data using the trusted data;and outputting the reconciled untrusted data.

Implementations may include some or all of the following features. Theuntrusted data comprises at least one of timing of insulin, amount ofinsulin, meal data, or activity data. The untrusted data is untrustedbecause of behavioral anomalies or human error in at least one oftiming, amount, estimation, or entry. The trusted data comprises atleast one of CGM data, insulin pump data, computer generated data,computer generated models, or an individualized model that describes theglucose and insulin dynamics of the subject. The method furthercomprises predicting a future glucose state of the subject based on thereconciled untrusted data. The untrusted data comprises reported carbs,wherein the reported carbs are unreliable or unavailable. The untrusteddata comprises a stream of data inputs. The method further comprisesreceiving additional untrusted data and reconciling the additionaluntrusted data using the trusted data. The method further comprisesreceiving additional trusted data and reconciling the untrusted datausing the additional trusted data. The method further comprises tuningan AP using the reconciled untrusted data. The method further comprisesupdating a behavior model of the subject using the reconciled untrusteddata. The method further comprises determining that the untrusted datais unreliable or unknown. Determining that the untrusted data isunreliable or unknown comprises computing, using modeling, localvariance of the untrusted data and comparing the local variance to theoverall variance using the untrusted data to determine a comparisonamount, wherein when the comparison amount is above a threshold, theuntrusted data is determined to be unreliable or unknown. Determiningthat the untrusted data is unreliable or unknown comprises determiningdifferences between the untrusted data and a model of trusted data.

Implementations may also include some or all of the following features.The method further comprises determining a credibility score for theuntrusted data relative to trusted data. The method further comprisesgenerating alerts pertaining to the subject based on the reconcileduntrusted data. The method further comprises determining behaviorpatterns of the subject using the reconciled untrusted data. The methodfurther comprises generating smart alerts pertaining to the subjectbased on the behavior patterns. The untrusted data comprises diabetesmanagement data. The diabetes management data is estimated diabetesmanagement data. The trusted data comprises diabetes management datacorresponding to the estimated diabetes management data, wherein thediabetes management data is received from a connected device or userentry. The method further comprises comparing the untrusted data to thetrusted data to identify a behavioral root cause of glycemicdysfunction.

Implementations may also include some or all of the following features.The method further comprises identifying a behavioral root cause ofglycemic dysfunction using the reconciled untrusted data. Thereconciling comprises: receiving the untrusted data at the inputreconciler, wherein the untrusted data comprises untrusted metabolicinputs; receiving the trusted data at the input reconciler, wherein thetrusted data comprises estimated untrusted metabolic inputs; andcombining the untrusted data and the trusted data using a weightingfunction to generate reconciled untrusted metabolic inputs. Theuntrusted data and the trusted data received at the input reconciler arein the form of vectors, and wherein the reconciled untrusted metabolicinputs are in the form of vectors. The weighting function is based ontime-relevance. The weighting function is based on relative confidenceof the untrusted data and the trusted data. The untrusted data comprisesreported untrusted metabolic inputs, and wherein the combining comprisesreconciling differences between the reported untrusted metabolic inputsand the estimated untrusted metabolic inputs. The reconciling comprisesmaking the reported untrusted metabolic inputs and the estimateduntrusted metabolic inputs consistent with a behavior model. Thereconciling comprises reconciling differences between the amount andtiming of the untrusted metabolic inputs and the estimated untrustedmetabolic inputs with measured data.

In an implementation, a method comprises receiving, at an inputestimator, untrusted data pertaining to a subject, wherein the untrusteddata comprises user entered data comprising at least one of insulindata, meal data, or activity data; and reconciling, using an inputreconciler, the untrusted data using trusted data pertaining to thesubject, wherein the trusted data comprises computer generated data.

Implementations may include some or all of the following features. Theuntrusted data comprises at least one of timing of insulin, amount ofinsulin, meal data, or activity data. The untrusted data is untrustedbecause of behavioral anomalies or human error in at least one oftiming, amount, estimation, or entry. The trusted data comprises atleast one of CGM data, insulin pump data, computer generated models, oran individualized model that describes the glucose and insulin dynamicsof the subject. The method further comprises predicting a future glucosestate of the subject based on the reconciled untrusted data. Theuntrusted data comprises reported carbs, wherein the reported carbs areunreliable or unavailable. The untrusted data comprises a stream of datainputs. The method further comprises receiving additional untrusted dataand reconciling the additional untrusted data using the trusted data.The method further comprises receiving additional trusted data andreconciling the untrusted data using the additional trusted data. Themethod further comprises tuning an AP using the reconciled untrusteddata. The method further comprises updating a behavior model of thesubject using the reconciled untrusted data. The method furthercomprises determining that the untrusted data is unreliable or unknown.Determining that the untrusted data is unreliable or unknown comprisescomputing, using modeling, local variance of the untrusted data andcomparing the local variance to the overall variance using the untrusteddata to determine a comparison amount, wherein when the comparisonamount is above a threshold, the untrusted data is determined to beunreliable or unknown. Determining that the untrusted data is unreliableor unknown comprises determining differences between the untrusted dataand a model of trusted data. The method further comprises determining acredibility score for the untrusted data relative to trusted data. Themethod further comprises generating alerts pertaining to the subjectbased on the reconciled untrusted data. The method further comprisesdetermining behavior patterns of the subject using the reconcileduntrusted data. The method further comprises generating smart alertspertaining to the subject based on the behavior patterns.

Implementations may also include some or all of the following features.The untrusted data comprises diabetes management data. The diabetesmanagement data is estimated diabetes management data. The trusted datacomprises diabetes management data corresponding to the estimateddiabetes management data, wherein the diabetes management data isreceived from a connected device or user entry. The method furthercomprises comparing the untrusted data to the trusted data to identify abehavioral root cause of glycemic dysfunction. The method furthercomprises identifying a behavioral root cause of glycemic dysfunctionusing the reconciled untrusted data. The reconciling comprises:receiving the untrusted data at the input reconciler, wherein theuntrusted data comprises untrusted metabolic inputs; receiving thetrusted data at the input reconciler, wherein the trusted data comprisesestimated untrusted metabolic inputs; and combining the untrusted dataand the trusted data using a weighting function to generate reconcileduntrusted metabolic inputs. The untrusted data and the trusted datareceived at the input reconciler are in the form of vectors, and whereinthe reconciled untrusted metabolic inputs are in the form of vectors.The weighting function is based on time-relevance. The weightingfunction is based on relative confidence of the untrusted data and thetrusted data. The untrusted data comprises reported untrusted metabolicinputs, and wherein the combining comprises reconciling differencesbetween the reported untrusted metabolic inputs and the estimateduntrusted metabolic inputs. The reconciling comprises making thereported untrusted metabolic inputs and the estimated untrustedmetabolic inputs consistent with a behavior model. The reconcilingcomprises reconciling differences between the amount and timing of theuntrusted metabolic inputs and the estimated untrusted metabolic inputswith measured data. The method further comprises performing replayprediction using the reconciled untrusted data and the trusted data. Themethod further comprises outputting simulated metabolic states based onthe replay prediction. The method further comprises performing real timeprediction using the reconciled untrusted data and the trusted data. Themethod further comprises outputting simulated metabolic states based onthe real time prediction.

In an implementation, a method comprises predicting data over a timeperiod for a subject; receiving untrusted data directed to management ofdiabetes; simulating a plurality of predictive data traces over the timeperiod using a spectrum of possible variances of the untrusted data;comparing the simulated predictive data traces to the predicted data toidentify glycemic effects; and outputting a visualization or arecommendation based on the glycemic effects.

Implementations may include some or all of the following features. Theuntrusted data comprises glucose data, and wherein the predictive datatraces comprise predictive glucose traces. Predicting the glucose datais based on trusted CGM data and an individualized model of theglucose-insulin kinetics of the subject. Predicting the glucose datacomprises providing a best estimate glucose trace representing glucosestate over time. The untrusted data directed to management of diabetescomprises at least one of a timing of insulin, an amount of insulin,meal data, or activity data. The glycemic effects are associated withdifferences in at least one of an amount of diabetes management data ora timing of diabetes management data.

In an implementation, a system comprises a processor and a metabolicmodel, wherein the processor is configured to receive untrusted userinputs and reconcile the untrusted user inputs with trusted inputs usingthe metabolic model.

Implementations may include some or all of the following features. Theprocessor is further configured to optimize the predictive ability ofthe metabolic model to predict future glucose levels. The processor isfurther configured to allow a replay of events and outcomes withalternate treatment procedures. The processor is further configured toprovide real time prediction of future metabolic states. The processoris further configured to determine the credibility of the untrusted userinputs. The processor is further configured to provide a scorecorresponding the credibility. The processor is further configured toperform a replay analysis directed to at least one replay application.The at least one replay application comprises assessment of bloodglucose (BG) outcome metrics in the analysis, identification of credibleinstances of scenarios in the replay analysis, evaluation of dataquality, credibility profiles, and data credibility as a function oftime of day. The processor is further configured to perform a reconciledprojection directed to at least one real time application. The at leastone real time application comprises confidence of medical actions anddetermination of need to wait before providing advice.

Implementations may also include some or all of the following features.The untrusted user inputs comprise estimated carbs. The untrusted userinputs comprise a time series of uncertain metabolic inputs. The trustedinputs comprise CGM and insulin pump readings. The trusted inputscomprise a time series of trusted metabolic inputs. The processor isfurther configured to output estimated metabolic states in time seriesform, final reconciled estimated metabolic states in time series form,and credibility of final estimated metabolic states and reconciledestimated inputs in time series form. The processor is comprised withina joint state/input estimator, and the metabolic model is a plugin.

In an implementation, a method comprises receiving, at an inputestimator, untrusted data pertaining to a subject, wherein the untrusteddata comprises user entered data comprising at least one of insulindata, meal data, or activity data; determining, at a credibilityassessor, a credibility of the untrusted data; receiving trusted data atthe credibility assessor; and updating, at the credibility assessor, thecredibility of the untrusted data using the trusted data.

Implementations may include some or all of the following features.Determining the credibility of the untrusted data comprises: determininga first credibility based on at least one of a lack of completeness ofthe untrusted data or a lack of continuity of the untrusted data;determining a second credibility based on expected behaviors indicativeof at least one of the lack of completeness of the untrusted data or thelack of continuity of the untrusted data; determining a thirdcredibility based on artifacts in estimated inputs indicative ofsystemic unknown factors; and aggregating the first credibility, thesecond credibility, and the third credibility. Determining the firstcredibility comprises using measured signals as an input, determiningthe second credibility comprises using the untrusted data and trusteddata as inputs, and determining the third credibility comprises usingthe untrusted data, estimated untrusted data, and reconciled data asinputs.

In an implementation, a method comprises receiving, at an inputestimator, first untrusted data pertaining to a subject, wherein thefirst untrusted data comprises user entered data comprising at least oneof insulin data, meal data, or activity data; determining, at acredibility assessor, a credibility of the first untrusted data;receiving, at the input estimator, second untrusted data pertaining tothe subject; determining, at a credibility assessor, a credibility ofthe second untrusted data; updating, at the credibility assessor, thecredibility of the first untrusted data using the second untrusted dataor the credibility of the second untrusted data; receiving trusted dataat the credibility assessor; and updating, at the credibility assessor,the credibility of the first untrusted data and the second untrusteddata using the trusted data.

Implementations may include some or all of the following features.Determining the first credibility of the untrusted data comprises:determining a first credibility based on at least one of a lack ofcompleteness of the untrusted data or a lack of continuity of theuntrusted data; determining a second credibility based on expectedbehaviors indicative of at least one of the lack of completeness of theuntrusted data or the lack of continuity of the untrusted data;determining a third credibility based on artifacts in estimated inputsindicative of systemic unknown factors; and aggregating the firstcredibility, the second credibility, and the third credibility.Determining the first credibility comprises using measured signals as aninput, determining the second credibility comprises using the untrusteddata and trusted data as inputs, and determining the third credibilitycomprises using the untrusted data, estimated untrusted data, andreconciled data as inputs.

In an implementation, a method comprises receiving estimated metabolicstates, reconciled estimated untrusted metabolic inputs, trustedmetabolic inputs, and alternative metabolic inputs; performing replayprediction using the estimated metabolic states, the reconciledestimated untrusted metabolic inputs, the trusted metabolic inputs, andthe alternative metabolic inputs; and outputting replay simulatedmetabolic states based on the replay prediction.

Implementations may include some or all of the following features. Theestimated metabolic states, the reconciled estimated untrusted metabolicinputs, and the trusted metabolic inputs each comprise a time series.Performing the replay prediction comprises estimating metabolic statesfor a duration of the time series for the estimated metabolic states,the reconciled estimated untrusted metabolic inputs, and the trustedmetabolic inputs to generate the replay simulated metabolic states.

In an implementation, a method comprises receiving alternative metabolicinputs, reconciled estimated untrusted metabolic inputs, trustedmetabolic inputs, and final estimated metabolic inputs; performing realtime prediction using the alternative metabolic inputs, the reconciledestimated untrusted metabolic inputs, the trusted metabolic inputs, andthe final estimated metabolic inputs; and outputting predicted metabolicstates based on the real time prediction.

Implementations may include some or all of the following features.Performing the real time prediction comprises: extrapolating time seriesfor the reconciled estimated untrusted metabolic inputs and the trustedmetabolic inputs; and estimating metabolic states into the future usingthe extrapolated time series, the alternative metabolic inputs, and thefinal estimated metabolic states. The method further comprises filteringthe extrapolated time series to prevent jitter in the predictedmetabolic states. The estimated metabolic states are in time seriesform. The method further comprises filtering the estimated metabolicstates to generate the predicted metabolic states. The estimating themetabolic states uses a behavior model of a subject. Extrapolating thetime series uses weighting of historical data based on at least one of atime of day, features of a current estimated state, or a database ofpast metabolic inputs.

It should be understood that the various techniques described herein maybe implemented in connection with hardware components or softwarecomponents or, where appropriate, with a combination of both.Illustrative types of hardware components that can be used includeField-programmable Gate Arrays (FPGAs), Application-specific IntegratedCircuits (ASICs), Application-specific Standard Products (ASSPs),System-on-a-chip systems (SOCs), Complex Programmable Logic Devices(CPLDs), etc. The methods and apparatus of the presently disclosedsubject matter, or certain aspects or portions thereof, may take theform of program code (i.e., instructions) embodied in tangible media,such as floppy diskettes, CD-ROMs, hard drives, or any othermachine-readable storage medium where, when the program code is loadedinto and executed by a machine, such as a computer, the machine becomesan apparatus for practicing the presently disclosed subject matter.

Although exemplary implementations may refer to utilizing aspects of thepresently disclosed subject matter in the context of one or morestand-alone computer systems, the subject matter is not so limited, butrather may be implemented in connection with any computing environment,such as a network or distributed computing environment. Still further,aspects of the presently disclosed subject matter may be implemented inor across a plurality of processing chips or devices, and storage maysimilarly be effected across a plurality of devices. Such devices mightinclude personal computers, network servers, and handheld devices, forexample.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A method comprising: predicting data over a timeperiod for a subject; receiving untrusted data directed to management ofdiabetes; simulating a plurality of predictive data traces over the timeperiod using a spectrum of possible variances of the untrusted data;comparing the simulated predictive data traces to the predicted data toidentify glycemic effects; and outputting a visualization or arecommendation based on the glycemic effects.
 2. The method of claim 1,wherein the untrusted data comprises glucose data, and wherein thepredictive data traces comprise predictive glucose traces.
 3. The methodof claim 2, wherein predicting the glucose data is based on trusted CGMdata and an individualized model of the glucose-insulin kinetics of thesubject.
 4. The method of claim 2, wherein the predicting the glucosedata comprises providing a best estimate glucose trace representingglucose state over time.
 5. The method of claim 1, wherein the untrusteddata directed to management of diabetes comprises at least one of atiming of insulin, an amount of insulin, meal data, or activity data. 6.The method of claim 1, wherein the glycemic effects are associated withdifferences in at least one of an amount of diabetes management data ora timing of diabetes management data.
 7. A method comprising: receivingalternative metabolic inputs, reconciled estimated untrusted metabolicinputs, trusted metabolic inputs, and final estimated metabolic inputs;performing real time prediction using the alternative metabolic inputs,the reconciled estimated untrusted metabolic inputs, the trustedmetabolic inputs, and the final estimated metabolic inputs; andoutputting predicted metabolic states based on the real time prediction.8. The method of claim 7, wherein performing the real time predictioncomprises: extrapolating time series for the reconciled estimateduntrusted metabolic inputs and the trusted metabolic inputs; andestimating metabolic states into the future using the extrapolated timeseries, the alternative metabolic inputs, and the final estimatedmetabolic states.
 9. The method of claim 8, further comprising filteringthe extrapolated time series to prevent jitter in the predictedmetabolic states.
 10. The method of claim 8, wherein the estimatedmetabolic states are in time series form.
 11. The method of claim 10,further comprising filtering the estimated metabolic states to generatethe predicted metabolic states.
 12. The method of claim 8, wherein theestimating the metabolic states uses a behavior model of a subject. 13.The method of claim 8, wherein extrapolating the time series usesweighting of historical data based on at least one of a time of day,features of a current estimated state, or a database of past metabolicinputs.
 14. A system comprising: at least one processor; and anon-transitory computer readable medium comprising instructions that,when executed by the at least one processor, cause the system to:predict data over a time period for a subject; receive untrusted datadirected to management of diabetes; simulate a plurality of predictivedata traces over the time period using a spectrum of possible variancesof the untrusted data; compare the simulated predictive data traces tothe predicted data to identify glycemic effects; and output avisualization or a recommendation based on the glycemic effects.
 15. Thesystem of claim 14, wherein the untrusted data comprises glucose data,and wherein the predictive data traces comprise predictive glucosetraces.
 16. The system of claim 15, wherein predicting the glucose datais based on trusted CGM data and an individualized model of theglucose-insulin kinetics of the subject.
 17. The system of claim 15,wherein the predicting the glucose data comprises providing a bestestimate glucose trace representing glucose state over time.
 18. Thesystem of claim 14, wherein the untrusted data directed to management ofdiabetes comprises at least one of a timing of insulin, an amount ofinsulin, meal data, or activity data.
 19. The system of claim 14,wherein the glycemic effects are associated with differences in at leastone of an amount of diabetes management data or a timing of diabetesmanagement data.
 20. A system comprising: at least one processor; and anon-transitory computer readable medium comprising instructions that,when executed by the at least one processor, cause the system to:receive alternative metabolic inputs, reconciled estimated untrustedmetabolic inputs, trusted metabolic inputs, and final estimatedmetabolic inputs; perform real time prediction using the alternativemetabolic inputs, the reconciled estimated untrusted metabolic inputs,the trusted metabolic inputs, and the final estimated metabolic inputs;and output predicted metabolic states based on the real time prediction.21. The system of claim 20, wherein performing the real time predictioncomprises: extrapolating time series for the reconciled estimateduntrusted metabolic inputs and the trusted metabolic inputs; andestimating metabolic states into the future using the extrapolated timeseries, the alternative metabolic inputs, and the final estimatedmetabolic states.
 22. The system of claim 21, further comprisinginstructions that, when executed by the at least one processor, causethe system to filter the extrapolated time series to prevent jitter inthe predicted metabolic states.
 23. The system of claim 21, wherein theestimated metabolic states are in time series form.
 24. The system ofclaim 23, further comprising instructions that, when executed by the atleast one processor, cause the system to filter the estimated metabolicstates to generate the predicted metabolic states.